For the ones that don’t know, Crystal was a 2018 hype (however the project exists since 2012) that I only found in 2019, basically it is a language very similar to Ruby in syntax, but that compiles to machine code and is statically type checked.
I was about to start a pet project using Raspberry Pi and Ruby when I noticed the existence of Crystal, so I used the occasion to learn Crystal, just one problem: There’s no crystal in archlinux for raspberry, or at least my efforts to find one weren’t enough.
Not a problem, let’s compile the Crystal compiler into raspberry! This would be amazing, but Crystal compiler is written in Crystal itself, so we have the egg-chicken problem here, the answer? cross compiling!
By my experience with C and C++, cross compile is a hell, but since Crystal is built on top of LLVM, I gave a try hopping for the best… and was very easy! :-)
My tests were using ArchLinux into a rPi, but this is so simple that must work on every distro.
First do a hello world in Crystal, save it as hello.cr:
Install crystal on your computer, sudo pacman -S crystal, then cross compile your hello-world program.
To know why the string “armv6l-unknown-linux-gnueabihf”, go to the rPi, install the llvm-package and type llvm-config --host-target, this is how LLVM describe the platform it is compiling for.
This will compile the file, generate a object file and print lines of code that you need to run in the host machine (the rPi) to link your program, i.e. a GCC command line.
So…. copy the hello.o file to the rPi, then we are going to try to link it. But not so fast, Crystal programs have some dependencies, all but one are solved by installing packages, so in your rPi install the following packages:
The missing dependency is libcrystal.a, a tiny one-file plain C static library that we are going to build from Crystal sources.
As I said, this library is just a single plain C file, so we just need to compile it and generate the static library in the rPi.
Then you can put libcrystal.a in /usr/lib/crystal/ext/ or in the same directory of the hello world. The crystal/ext directory is better, since the link commands the Crystal compiler tell us use this, so we need to change nothing.
Now with everything ready, just link your object file with the commands supplied by the crystal cross compilation.
If you think this is too much job… or you are too young in the cross compilation world or I’m too old to remember how painful was to cross compile anything to ARM.
If you have a Windows 32bits and want to try RubyCreator I present you the first RubyCreator binary distribution!
Only Windows 32bits is available since I only have a Windows7 32bits VM available. Consider the Windows distribution beta, I don’t test/use it everyday like I do with the Linux version.
This hand in the screenshot is from my Linux desktop and I’m too lazy to go there take another shot, since I compiled and tested using a VM.
I turned off font anti aliasing, with it on I was not able to proper see the bold text used in RubyCreator sintaxhighlighter, I also didn’t test the Rubocop integration, but it should work, to try it: Add ruby to the system path and make the rubocop gem available for it.
To install it go to Github releases page, download the zip file, unzip and copy the Ruby.dll file to the QtCreator plugins directory. Restart QtCreator and done.
The binary distribution is GPG signed (.sig file) if some nerd want to check if was really me that created it, BTW I need create a new GPG key, mine is too old.
I finally spent some time to try to compile RubyCreator on Windows, I don’t use Windows and dislike it as a development environment so this is why it took so long, here I’ll describe the steps to get it compiled and working, in a near future I plan to do binary distributions for RubyCreator, so will be easy for Ruby Windows developers to get it.
While there is no binary distribution, you need to compile it yourself, so here is the slow and painful instructions, ok, not so painful, but requires a log of time and downloads.
To get it done you will need.
Patience, 1Kg is enough.
Download Microsoft Visual Studio Express 2013 (QtCreator binary distribution was compiled with it, so the plugins should use the same compiler).
Download Qt for Visual Studio 2013 (The huge package with 840Mb)
Get the QtCreator sources from somewhere or clone it from git (firstname.lastname@example.org:qtproject/qt-creator.git). Try to do a shallow clone to avoid download the whole QtCreator git history.
As the QtCreator binary distribution does not come with all the data we need to be able to compile any plugin, you will need to compile QtCreator first.
Open the MSVC2013 Developer Command Prompt.
Add the Qt bin directory to the system path, so you can call qmake.
C:\> SET PATH=%PATH%;C:\Qt\Qt5.6.0\5.6\msvc2013\bin
Go to the directory you cloned QtCreator.
Checkout to the tag matching the version of QtCreator you want to compile, in this case same version of QtCreator you already have installed on your system.
Prepare to do a out of source build:
C:\...\QtCreator> cd ..
C:\...\> mkdir QtCreatorBuild
C:\...\> cd QtCreatorBuild
C:\...\QtCreatorBuild> qmake ..\QtCreator\qtcreator.pro
Now go find something to do, because this will take some time.
You are closer… just a few minutes.
Open the MSVC2013 Developer Command Prompt and make sure qmake is on system path like you did to compile QtCreator.
Go to directory you clonned RubyCreator.
Change to the branch that match the QtCreator version (qtc-3.6 for QtCreator 3.6.x).
Compile it :-)
C:\...\RubyCreator> cd ..
C:\...\> mkdir RubyCreatorBuild
C:\...\> cd RubyCreatorBuild
C:\...\RubyCreatorBuild> qmake QTC_SOURCE=..\QtCreator QTC_BUILD=..\QtCreatorBuild ..\RubyCreator\ruby.pro
The plugin is called Ruby.dll, you can find it somwwhere in the QtCreatorBuild among with other plugins, copy it to your QtCreator plugins directory, restart it and done.
Need to compile the entire QtCreator to just compile a small plugin is a pain in the ass, life would be easier if QtCreator packages had the necessary bits to compile plugins.
After almost 2 years I can say, “KDE, I’m back”. I used KDE3 during their entire life time, but KDE4 was horrible,
nothing worked well, the network manager applet was terrible and everything was a mess… plus slow as hell.
So in the meantime I was using a setup based on OpenBox plus many small applications, like the 90’s, everything
worked well and ultra fast! But the need to open a terminal and learn how to use xrandr just to attach a
external monitor without a reboot was also horrible… so I gave a try to KDE5 and it seems way better than KDE4, ok, kwin still slow and causing a lot of pain with the default configuration, but things are getting better.
So… I tried to help KDE5 with something simple that would not waste my time spent in my pletora of pet projects, and the simple thing was a stupid application that I see myself using from time to time, KColorChooser, the application is nothing but a way to pick colors from screen, just that, so I ported it to KF5 :-), the application is really stupid so the port took some minutes, but the code review some weeks, here’s it, if you know Qt you will notice that it is just a QColorDialog with an extra help button.
That’s it, it will be released on KDE applications 16.04 IIRC :-)
If you are not alone on a project you probably have some kind of code review, if it’s not explicit at least someone will at some point see what you did and blame it.
There are plenty of code review tools out there, free, non free, too much simple, too much complex, etc… most of them didn’t attended my point of view of what a code review tool should be. In my point of view any tool should be just a tool, any good developer is too busy with the problems it must solve to waste time configuring, learning, using tools, tools should exists to help not to create yet another thing to worry about.
This doesn’t mean all other code review tools are shitty, phabricator is a nice one, gerrit fit on some more complex workflows, etc… but let me introduce what my code review tool have:
An ugly logo
…and a name: Review it!.
Simple Web interface, just for code review, nothing more
The web interface is super simple, it allows you to see the various versions of the patch, accept, reject of comment on patch lines. Just this.
Accepted patches go to the git repository without need of any extra manual step.
Simple CLI interface for simple things
Send a merge request is a matter of type review push master, this mean: “Push the git commit on HEAD for review targeting the master branch.”
To update a merge request is even easier, review push.
See pending reviews? review list.
Open a merge request on your browser? review open ID.
Apply a merge request patch on your tree? review apply ID
Show a merge request patch without open the browser? review show ID
Oops, want to cancel a merge request? review cancel ID
The idea is simple, simple commands for simple things.
(almost) Zero configuration needed
To configure the CLI is also much simpler, go to the Web interface, copy and paste the command on your terminal (in the project directory), something like