Sunday, December 10, 2017


If you use Free Pascal and/or Lazarus and update them often to follow the development in trunk, or if you just need to use multiple versions side by side, have a look at fpcupdeluxe (GitHub).
It's a GUI front-end which lets you easily select a release and build it, including cross-compilers, with a click of a button. The result is installed into its own directory where it doesn't interfere with any other installations of Free Pascal and Lazarus.

If you haven't yet, check out the latest releases of both Free Pascal (3.0.4) and Lazarus (1.8) published recently.

Update: It seems the latest fpcupdeluxe (1.6.0k) now builds trunk without any problems, no tweaks necessary, so you can ignore the rest of this post.

As a side note, updating trunk today failed for me when it was trying to build the intermediate ("bootstrap") compiler. I haven't thoroughly investigated it but I think it's due to the fact that fpc 3.0.4 is now the required compiler to build trunk and I have found a quick fix which works for me now and comprises the following two steps:

1. Create a patch file with the following content in $(fpcupdeluxe)/patchfpc directory:

Index: Makefile.fpc
--- Makefile.fpc (revision 37707)
+++ Makefile.fpc (working copy)
@@ -21,7 +21,7 @@
 # make versions < 3.77 (OS2 version) are buggy

and activate it in the fpcupdeluxe's settings (see screenshot below). This should "force" the bootstrap compiler 3.0.4 to be used instead of 3.0.2 as before.

2. Click "Trunk" and let fpcupdeluxe clone the 3.0.4 release into its fpcbootstrap subdirectory. This would still fail for me as for some reason the generated bootstrap compiler was still 3.0.2. Just replace the binary (ppcx64) with the 3.0.4 binary (you can build one yourself from source or copy it from the official release).

On the next click of the "Trunk" button, you should get a successful build of the current trunk fpc (3.1.1) and Lazarus (1.9). Updating the cross-compilers then worked for me again as well. I usually use x86_64-linux and cross-compile to arm-linux, i386-linux, x86_64-win64, i386-win32, x86_64-darwin and i386-darwin.

Friday, May 19, 2017

Big Ball of Mud

Recently I've spoken to people at quite a few companies where Delphi is used to develop their software. There's a pattern which is very hard to miss or ignore: Every one of them so far wants to get away from Delphi. They are all very dependent on it and still need it to continue running their businesses but they are unhappy about it and their long-term plan is unequivocally to move away from it. Often they would like to migrate to the Web, using the browser as the user interface and things like Microsoft ASP.NET and Azure as the back end.

An often-mentioned reason why they'd like to migrate away from Delphi is that their systems evolved into what can be described as the "Big Ball of Mud".

But wait. How's that related to a particular language or development environment? This (anti-)pattern applies to software design in general, right? Regardless of the language or the IDE?

Think about how fast and easy (compared with other tools) you can bang out a quick prototype in Delphi. Think about how often those prototypes end up in production after all, never rewritten or revisited again. In the article above, they are referred to as the "throw-away code"; code which was supposed to be thrown away but for some reason that never happened.

Which is what, as the throw-away code accumulates, eventually leads to the Big Ball of Mud pattern.

Does perhaps Delphi, by making it so easy to produce throw-away code, support a tendency leading to the creation of "Big Ball of Mud" systems?

What do you think?

Saturday, December 24, 2016

Colours on my keyboard

A few days ago I had to consider reinstalling Windows on my notebook. Instead I decided to switch to Linux Mint. I've been using Linux Mint in virtual machines for a few years and it worked very well for me. This is the first time I run Linux directly on the host. For development I keep a few Windows virtual machines. I'm very happy with it so far. Everything just worked without much ado, except one detail: The notebook comes with a backlit keyboard with configurable colours. Under Windows I got used to setting it to a dim white colour which works best for me. Since the default colour on boot is dark blue I was looking for a way to change it in Linux. Luckily, I've found a driver for it.

Big kudos to Steven Seeger (klystron) for his efforts!

I can enjoy my comfortable dim white colour again. Or play around; see below. ;-)

Happy holidays and a great year 2017 to everyone!