@phil_pirozhkov I believe Crystal needs it's own runtime because of it's GC. Doesn't appear possible to compile a shared library.

@jaredmoody there's also a period of development where you're still figuring out the object model, and classes/methods tend to move around more. Dynamic languages won't care until you call the wrong thing. Typed compiled languages will halt the compiler if just one thing is out of place.

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.
travis-ci.org/ronin-ruby/ronin

travis-ci.org/postmodern/diges
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

github.com/postmodern/digest-c 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...
github.com/ruby/ruby/blob/e4a9

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.
github.com/ruby/ruby/blob/1641

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`:
github.com/ruby/ruby/blob/14dd

Show thread

github.com/ruby/ruby/blob/mast 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.

@james I, for one, look forward to the quarantine. Will hopefully make progress on my OSS backlog.

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.

WIP github.com/postmodern/digest-c

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

Ported digest-crc to Crystal, which also lead me to making improvements to digest-cr. Fixed a few things, added more CRC algos from pycrc, and did a code spike last night to build C extensions for the pure-Ruby `update` methods and override them when loaded. Appears to work fine when build manually. Now, if only I could get rake-compiler to work... :/

-compiler

@watzon ah ha. I too was disappointed by the built-in Spec library not having expect(), subject { }, let() { }. It's nice that the stdlib has so much built-in, but we've largely become used to RSpec 3.0's syntax.

Show more
Ruby.social

A Mastodon instance for Rubyists & friends