Is there an authoritative list of the deprecated Gem::Specification attributes?

Updated rubocop and now it's saying gemspec.test_files is deprecated, but I want to be sure that's the case before I remove that code.

Ah, I just noticed that IO#each_line supports a `chomp: true` option much like `readline`. This whole time I've been adding `line.chomp!`.

Any method that accepts "getline_args" will support `chomp: true`.

FYI if you notice Ctrl^U not working in irb on ruby < 3.2.0, `gem update reline irb` to get the latest version.

Figured out how to convert sign-extended C integers to negative Integers in Ruby:

int = uint & ((2 ** bits) - 1) - (2 ** bits)

assuming uint = 0xffffffff and bits = 32:

(0xffffffff & ((2 ** 32) - 1) - (2 ** 32)
(0xffffffff & (0x1000000 - 1)) - 0x100000000
(0xffffffff & 0xffffffff) - 0x100000000
0xffffffff - 0x100000000

and to determine if the C integer is negative or not, just check the MSB:

uint[bits-1] == 1

Just noticed Ruby added String#b, which I assume is to riff off of Python's b-string syntax, which are not really liked in the Python community. Much prefer my `String.ascii` and `String#to_ascii` core-exts.

So what's the state of VSCode Intellisense, but for ruby gems? Can it automatically scan the RI index of all installed gems, or do projects have to generate their own API index file for VSCode?

I liked irb's auto-suggestion drop-down list feature at first, but ugh, the fact that it auto-scrolls your terminal up each time is SUPER annoying. Really hope the irb team changes it to always popup the list window in a fixed location and not auto-scroll.

and if you choose `Foo::`, what file name should these constants be defined in to make it easy for other files to require them and only them? Or should they be defined in separate files?

Show thread

`Foo::Gem::` might cause some shadowing issues with the main `Gem::` namespace if `Foo` is meant to be included into other modules, but I listed it anyways.

Show thread

What would be a good module namespace for storing constants related to your gem itself (ex: `ROOT`, `DATA_DIR`, etc)?

Another method I keep needing, `String#each_index` or `String#find_all` which would find each index/length of a given substring/Regexp within the String. Basically find the pattern starting at pos, pos = index+match.length, repeat.

I still wish there was a combination of `Dir.glob` and `File.join`, as people mostly use those together to find all absolute paths within some other directory.

Show thread

I didn't realize `Dir[...]` can accept multiple glob patterns, which it then evaluates individually. Also that it accepts a `base:` path key argument.

Is there a performance hit for overly nesting embedded Regexps? I noticed some parsing code in Ruby stdlib defines Regexp components as Strings instead of Regexps, and then embeds those in the main Regexp; possibly to avoid needless (?-mix:...) nesting?

Released bundler-audit-0.9.1 to fix a regression with the rake task that was introduced in 0.9.0. If you use the rake task in your CI, upgrading to 0.9.1 is highly recommended.

Big news for Ruby. Shopify is investing heavily in improving Ruby performance and have put together a dream team of researchers.

What's a good Graph Database, that isn't Neo4J. Looking for a simple Graph Database solution. Bonus points if it has a good Ruby or Crystal client library.

What would be a better namespace name then `OpenSSL::PKey`?

Turns out I was doing something wrong... 😳 However, the different ways that the async gem allows nesting Async blocks confused me and caused me to thrash. Where as Crystal's simple non-nested spawn blocks and Channel queues made implementing the concurrent logic much easier.

Show thread
Show older

A Mastodon instance for Rubyists & friends