aaaaand released digest-crc 0.6.1 because of course I forgot that bundler requires rake be listed as a dependency, even though it's bundled with ruby. Now digest-crc will successfully install/compile under bundler.

Show thread

FYI digest-crc 0.6.0 is out. 40x performance improvement for CRuby! If you use ruby-kafka (which uses digest-crc) run `bundle update digest-crc` to take advantage of the performance boost.

TIL snap's snapcraft.yml format is similar to my gemspec.yml format. A win for package metadata simplicity!

Kind of wish that Enumerable#filter_map was aliased as , because that's what it basically does.

FYI digest-crc 0.6.0.rc1 is out! Optional C extensions yielding 40x performance boost on CRuby! Please test installing it on various rubies/platforms.

`gem install digest-crc -v 0.6.0.rc1`

Working on my Open Source backlog. Released -audit 0.7.0 that fixes a few outstanding bugs and adds a few things. Now to finish writing specs for 0.8.0...

Playing with -lang reminds me of my Java days. Constant back-and-fourth between annoying compiler errors and editing. Definitely appreciate how Ruby let's you hit the ground running with irb.

Well this is a first. Trying to resurrect some old Ruby repos but Travis CI is flagging my pushes as Abuse.
oh figures. Ruby 2.5 lacks USHORT2NUM macro, but the C compiler treats undefined macros as undefined symbols. Ruby's C macros are the cruftiest part of the API.

Show thread recent benchmarks of pure Ruby CRC algorithms vs. the optional C extensions. Looks like a +90% performance improvement across the board 😮

Starting to regret avoiding C extensions for all these years 😕 (although they are still a PITA to write and C is not a safe or secure programming language...)

TIL mkmf's `create_makefile` cannot be called multiple times to generate multiple separate Makefiles, because it's a dumpster fire of global variables...

I'm really curious if there's an example out there of building Ruby C Extensions using a Rakefile (ie `gemspec.extensions = ["ext/foo/Rakefile"]`) instead of the standard `extconf.rb` method? This might allow me to optionally build C extensions, and fail gracefully if there's no C compiler, no headers, no libruby, etc.

Ah yes I remember now. The bulk of the C extension building logic is in RubyGems itself. RubyGems will execute extconf.rb, then try to run the resulting Makefile, or error if none was generated.

Fun fact: RubyGems supports `./configure`, `Rakefiles`, and even `CMakeLists.txt` files in `gemspec.extensions`:

Show thread trying to understand how try_compile causes the extconf.rb file to exit -1 if it fails. mkmf.rb is a tire fire, but amazingly works on any common *nix platform.

Nothing more demotivating than dealing with crufty old tests...

While I like that Ruby 2.7 has pattern matching, the case/in keywords seem a bit off... Would prefer case/is, case/match, or case/like.


Still need to figure out how to make extconf.rb fail gracefully when it cannot build C extensions (ie: no C compiler, ruby-dev/ruby-devel not installed) and print some "Skipping ..." message.

Show thread

also need to figure out how to optionally build C exts. Say a user installs my library, but doesn't have gcc installed. I'm sure there's a way to make extconf.rb fail silently. Then you'd just have to put `begin/rescue LoadError` around where you load the C exts.

Show thread

I really like the idea of writing 100% of your code in Ruby, then creating optional C extensions which hook-in and replace "hot" methods with optimized C equivalents. This just requires that you have individual C exts (`extconf.rb` and `myext.c`) for each Class/Module you wish to hook into. Then at the bottom of each myclass.rb/mymod.rb, you'd add:

require 'mylib/myclass_ext` if RUBY_ENGINE == 'ruby'

which only loads the C exts on MRI; JRuby/TruffleRuby/etc can probably optimize the Ruby.

Show thread
Show more

A Mastodon instance for Rubyists & friends