Happy Friday!


Another week down and I’m trying to motivate myself for some weekend developer activity. I’ve been out of it lately and taking a hiatus on #SaturdayCoding but this has to stop. Hi, I’m Cliff. You’re probably here because you write code. (It’s either that or you know me from high school or seen me at church. If you’re part of the church crowd don’t run off! You might pick up something useful!) On the drive home I was seriously thinking of picking back up on Android development. Then when I hit the front door I began considering my unfinished robotics projects. It’s so easy to get distracted, however I feel like I should re-acclimate with Android Studio as it’s been so long!

The last serious bit of Android code I wrote was close to a year ago when I was helping to build out an SDK. I’m not even sure what an Android app would look like these days! So much has changed. Should I continue to use Java? Should I tackle my next project in Kotlin? How about writing a game in Lua?? I do have some overdue work on another hybrid app I started a while ago. That means more Javascript/HTML which has all of a sudden become the only tech I use these days. (I never thought I’d be so heavily into browser tech but here I am!) The project also involves a nodeJS backend which I might try to tackle with Ruby/Rails instead… just for practice. All these languages feel so long in the tooth. I desperately need a change. I am so itching to do something with Lua embedded in a C++ thing with some OpenGL touches for good measure.

I know! Maybe I could dive into the Android NDK and stretch my C++/Lua wings there! Or maybe not… This hybrid project is calling me. It’s a promise I made to a friend that I shouldn’t let sit too much longer. Enough rambling for now. I really should to fire up one of my IDEs. Which one do I choose???

[ ] IntelliJ
[ ] Android Studio
[ ] Xcode
[ ] VSCode

Something’s wrong with my Pumas


Maybe it’s ironic that I decided to wear my Puma sneaks to work today, on the very same day I get into trouble installing the puma gem. Maybe it’s ironic that I tweeted something whacky about my Pumas just yesterday. Maybe it’s also ironic that Alanis Morissette decided to collaborate with me on this blog post. (Okay, that last point isn’t totally true.) Hi, I’m Cliff. You’re here because you don’t wear Puma sneakers. I’m here because I spend so much money on my family that I can’t afford to upgrade my kicks.

Just the other day I felt like I finally mastered RVM/Ruby/Rails. Today I hit another snag. Hold up though, this snag wasn’t as bad. You see, I think the Lord allows us to have trouble installing software like RVM in order to prepare us for the devil that comes out when you start installing other software like the puma gem. If I didn’t pay particular attention and read my error messages I would be scratching/snatching another bald spot into my scalp. The error I was getting was in the middle of a bundle install when it hit the puma gem. The last part of the error was:

3 warnings and 4 errors generated.
make: *** [mini_ssl.o] Error 1

make failed, exit code 2

Gem files will remain installed in
/Users/c.craig/.rvm/gems/ruby-2.3.3@tutorial/gems/puma-3.4.0 for inspection.

I could have figured it out from this text alone but I looked further up in the error messages just to be sure.

/Users/c.craig/.rvm/gems/ruby-2.3.3@tutorial/gems/puma-3.4.0/ext/puma_http11
make "DESTDIR="
compiling http11_parser.c
ext/http11/http11_parser.rl:111:17: warning: comparison of integers of different
signs: 'long' and 'unsigned long' [-Wsign-compare]
  assert(pe - p == len - off && "pointers aren't same distance");
         ~~~~~~ ^  ~~~~~~~~~
/usr/include/assert.h:93:25: note: expanded from macro 'assert'
(__builtin_expect(!(e), 0) ? __assert_rtn(__func__, __FILE__, __LINE__, #e)
: (void)0)
                        ^

This looked suspiciously like the error I got the other day. The problem seemed to be related to compile errors where the compiler was using the wrong version of openssl headers. I tried to use the same command line flag to see if the error would just disappear but that wouldn’t work.

gem install puma -C --with-openssl-dir=$HOME/.rvm/usr

Then I thought I would just upgrade to a different/newer version of Ruby instead of using the problematic 2.3.3 version that first introduced the problem. After upgrading to Ruby 2.5 I still saw the error. After a bit of Googling I found that I just needed a slightly different variant of the command line flag to point the gem installer to use the same openssl headers I installed for Ruby 2.3.3. The command to install the puma gem turned out to be:
gem install puma -- --with-opt-dir=/path/to/custom/openssl

I ran that and my errors went away! All in a day’s work! The lessons learned here are

  • Don’t panic when a given gem fails to install without errors.
  • Read your error messages carefully even/especially when you don’t understand them.
  • Don’t wear Puma sneakers to work.

Of all the bullet points the last one is most important.

Can’t see nothing but the source code, I’m trippin’


We begin another year with more Ruby/RVM drama. First, a recap: In our latest episode, filmed last Friday, we discovered a problem with Ruby 2.3.3 and openSSL on OSX.

Me: rvm install 2.3.3

OSX: Nah, bruh! You are not slick enough, nor do you possess the lyrical skills to master this pristine version of Ruby. Get ya weight up!

Me: What the???!!!

Me: rvm reinstall 2.3.3p222

OSX: Srsly bruh? I said nah! Come back when ya game is tight! (Oh and your hat is plaid out!)

Me: How does this have anything to do with my game???!!!

Me: rm -fr ~/.rvm

Me: [repeats above steps with slightly different “game”]

Several iterations later we found the magic to satisfy some build-time macro that was getting in the way of the installation “game”. Hi, I’m Cliff. You’re here because you ain’t got any programming “game”. I’m here because I actually thought my baseball cap look was stylish when it really ain’t. In either case we now have a working Ruby installation but no way to properly install and run bundler. For those who don’t know, bundler is a Ruby gem that works similar to npm in NodeJS. It manages dependencies.

I’ve spent the better part of my morning arguing with my command line in failed attempts to bundle install anything. What I get are various errors indicating a missing executable in some user directory of some sort. It’s not immediately clear:

You're whack and I cannot load such a file... $HOME/.rvm/rubies/ruby-2.3.3/lib/ruby/gems/2.3.0/gems/bundler-1.16.6/exe/bundler (LoadError)

I’m paraphrasing the error slightly, but you get my point. This comes after a clean RVM install of Ruby 2.3.3, which I just learned is “a ruby that requires 2 patches just to be compiled on an up to date linux system.” I was so generously warned about this post install. It’s also after a successful gem install of bundler with that same Ruby. So I was thinking it’s as if my environment is set to use some default or global version of bundler. The confusion is that bundler is not installed with the 2.3.3 Ruby I pulled using RVM. So I’m not quite sure why it’s looking in that path or bundler. I don’t have enough Ruby experience to know the difference between user installed, system installed, default and/or global gems so then I was stumped.

Believe it or not, I got all the way to the above sentence where I said, “I’m stumped” before the obviousness of my problem jumped out at me. It really jumped off of my LCD display and slapped me across the face like, “C’mon homie! Don’t act like you can’t see what’s wrong here!” I was issuing all of my bundle commands with a trailing r! I know I’m not the only person who confuses "bundler install" and "bundle install"

Installing software that installs software to write software


I should be home right now but I can’t leave the office until I document what felt like an extreme waste of time. Hi, I’m Cliff. I write software. Sometimes I write software that installs software. Sometimes the software installed by software I originally wrote is intended to install other software which I’m not clever or available enough to write. Sometimes the software installed by the software installed by the software I originally wrote… are you following me? It’s cool if you’re not.

Today’s pain came from RVM and Ruby version 2.3.3 on OSX. I hit a bug that I am almost certain I ran into before but I don’t have any evidence of it on this blog. Today I am generating the evidence. Github user TheZoq2 solves the mystery in this thread.

Error running ‘__rvm_make -j8’

In short, This particular version of Ruby depends on openssl headers that don’t match the openssl installed by the Xcode developer tools. The solution is to install the Ruby openssl package, and reinstall Ruby 2.3.3 while pointing the C compiler to its headers.

$ rvm pkg install openssl
$ rvm remove 2.3.3
$ rvm install 2.3.3 -C --with-openssl-dir=$HOME/.rvm/usr

Short story lengthened… You wouldn’t know that from the above error. The only way you could figure this out is by reading the entirety of the error message. Somewhere after the rvm install fails it tells you to look inside a log file for details. Somewhere inside this log file you’ll see evidence of the make build system choking on macro arguments and the like.

So, in summary… if you wanna suck at programming, install Ruby version 2.3.3 via rvm. You won’t burn down your development machine doing so but you also won’t have any hair left on your head, eyebrows, or eyelids after several attempts to make sense of what “-j8” means.