The Unit Testing workshop was pretty much full.
It was good to see that many interested Delphi programmers in one room. Thanks for coming, everybody!
The downloads for the workshop are now online.
On March 19th (that’s next Thursday), I’ll be leading a workshop dedicated to unit testing Delphi programs. We’ll start with basics and and cover different tools (DUnit, DUnit2, DUnitX, TestInsight) and different programming methodologies.
Some other links you may need:
Home page: http://www.omnithreadlibrary.com/
Google+ community: https://plus.google.com/communities/112307748950248514961
Issue tracker: http://code.google.com/p/omnithreadlibrary/issues/list
SVN checkout instructions: http://code.google.com/p/omnithreadlibrary/source/checkout
Author's blog: http://thedelphigeek.com
Author's home page: http://primoz.gabrijelcic.org
Documentation wiki: http://otl.17slon.com/book/
Documentation book: http://leanpub.com/omnithreadlibrary
Blocking collections (IOmniBlockingCollection) are basic elements for data storage and transfer in many high-level OmniThreadLibrary abstractions. They can, however, be somewhat clumsy when you want to read data from them, as there is no indexed access, just the basic “give me next element” enumeration.
To help a bit, SVN now includes three new class functions in the TOmniBlockingCollection class – ToArray<T>, ToArrayIntf<T>, and ToArrayRec<T>.
class function ToArray<T>(coll: IOmniBlockingCollection):
class function ToArrayIntf<T: IInterface>(
coll: IOmniBlockingCollection): TArray<T>;
class function ToArrayRec<T: record>(
coll: IOmniBlockingCollection): TArray<T>;
odds : TArray<string>;
//initialize the `numbers` array (not shown)
odds := Parallel.Map<integer,string>(numbers,
function (const source: integer; var dest: string): boolean
Result := Odd(source);
if Result then
dest := IntTostr(source);
//do something with the `odds` array (not shown)
Yesterday I hinted at having a working (and easy to use) solution which allows you to detect a record assignment (or copying, if you want) and to access both records (left and right part of the assignment operation). You can also modify record data when an assignment is detected. I also mentioned that my approach is very ugly, unstable, likely to cause problems in future Delphis and so on. You should read this article for the technical details, not to really use my code in an application. You have been warned!
Before I jump to hardcode Delphi stuff, I’d like to mention few different approaches that various smart people have already implemented. Most of them slipped below my radar in the past – and I’m guessing this may be the case for you too – so I’m listing them here in case you want to do more research on the topic.
Following the yesterday’s hunch, I did some research and I came up with a way to detect when a record is copied (simple, supported, working everywhere) and even to access both records (source and target) during that operation (unsafe, unsupported and currently working only for Win32).
Now I can write such code:
Smart records in Object Pascal are very nice, but they have a stupid limitation – you cannot implement a destructor for a record.
A solution for that is quite simple and can be found all over the internet – add an interface to this record and implement the cleanup in this interface. To make it even simpler, you can use the IGpAutoExecute interface from the completely free GpStuff unit.
Paweł’s recent post reminded me of a veeeeeery old raytracer I wrote in years 1985/89. (Yes, young ones, we had computers then!)
Language: Pascal V2
Language: Turbo Pascal 4.0
Graphics: EGA 640 x 350 x 16
Language: Turbo Pascal 5.0
Graphics: VGA 800 x 600 x 256
Quite a blast from the past – the 800 x 600 in 256 colors (out of a great palette of 262144 colors!) was more or less the greatest graphic card which you could get for PC at that time. And the first version was running on a VT100 terminal with an additional graphics board. Sadly, I don’t have that code anymore :(.
Oh, command line parsing, the old enemy of mine!
In ye olden days, when I was learning Pascal, I did some programming on VAX/VMS systems, where you could (and should) leave the job of command line parsing to the DCL – the command line interpreter (something like CMD.EXE on Windows). You just wrote a definition file (see example on the right, found on the web) and DCL did the rest.
Since those days I hated that I have to parse command line programmatically. Sure, there were parsing libraries – and I wrote few of them myself – but I was never happy with them. There was always too much code to write.
Then I was looking for good examples on using attributes in Delphi and suddenly it occurred to me that I could use them for command line parsing, too! And that’s how GpCommandLineParser was born.
Before continuing, I should mention that I have based it (concept-wise, implementation is all my own) on the CommandParser unit, which comes with Delphi and can be found in Samples\Object Pascal\Database\dbExpress\Utils. This is a very nice but mostly unknown command line parser which I can definitely recommend.
I have (finally!) implemented support for more than 60 simultaneous tasks in the OTL thread pool and for more than 60 waitable events in the IOmniTaskControl. This also enables support for massively parallel execution in OtlParallel abstractions. IOW, Parallel.ForEach will run correctly on machines with 64 and more cores without needing to call NumTasks(60).
I’ve been testing this change and I think that it’s working correctly, but it is a big (and potentially dangerous) modification and so I’d like to see additional testers trying the new version in real programs before I submit it to the SVN.
So – if you like to live on the edge, if you’d like to help improve OTL and especially (but not required!) if you can test the code on a machine with 64 or more cores, please download the 3.04b1 from Dropbox and try it out. You can post reports here or send them to my email (my address is in the header of every OmniThreadLibrary file). In case of a problem, a short, repeatable, self-contained example will be of an immense help.
A note for Slovenian readers.
Ne pozabite – jutri bom predstavil novo knjižnico System.Threading, ki olajša razvoj hitrih in odzivnih programov za vse platforme, ki jih podpira RAD Studio – Windows, OS X, iOS, Android – ter v obeh programskih jezikih – Delphi in C++. Ogledali si bomo tudi novosti v knjižnici OmniThreadLibrary.
Za več podatkov in prijavo kliknite tu!
This is an invitation for the XE7 workshop in Slovenia which is targeted at Slovenian programmers.
RAD Studio XE7 prinaša nov način paralelizacije programov. S kodo, zbrano v enoti System.Threading lahko na enostaven način pohitrite nekatere funkcije v programih, tako da se izvajajo sočasno z drugo kodo. Še lepše - System.Threading deluje na vseh podprtih platformah, torej poleg Windows tudi na OS X, iOS in Androidu. Na delavnici si bomo podrobno ogledali nove načine paralelizacije in pregledali druge knjižnice, ki podpirajo hkratno (paralelno) izvajanje v okolju Windows.
Predavanje bo v četrtek, 27. novembra, 2014.
If you install RAD Studio XE7 and then upgrade Android SDK to version 23, you won’t be able to deploy applications to Android devices anymore.
The reason for that is that ZipAlign.exe was moved out of sdk\tools folder in SDK 23 and XE7’s deployment process cannot find it anymore. Now it is located in sdk\build-tools\20.0.0, but only is Android SDK Build-tools rev. 20 are installed, which doesn’t happen automatically.
To fix my Delphi I first had to install Build tools rev. 20. Then I copied sdk\build-tools\20.0.0\zipalign.exe to sdk\tools\zipalign.exe. That fixed the deployment problem.
I’m hoping Embarcadero will fix this in the next update, but for now you can use this workaround.
[Android sdk folder can be found in c:\Users\Public\Documents\Embarcadero\Studio\15.0\PlatformSDKs\adt-bundle-windows-x86-20131030\sdk]
This is a job offer for a full time programming job in Ljubljana.
Iščemo Delphi programerja za dolgotrajno razmerje; človeka, ki se ne ustraši stare kode in z veseljem programira s sodobnimi orodji. [XE2, prehod na sodobno različico je že v teku in ga bo pomagal zaključiti prav programer ali programerka, ki ga iščemo.] Delo se opravlja v pisarni v Ljubljani.
Več o podjetju: www.fab-online.com. Kontakt: primoz (pri) fab-online.com.
A snapshot from the XE7 presentation in Ljubljana.
Highlights of the presentation were FireUI, System.Threading, dynamic arrays, and OmniXML.
‘Twas a very nice crowd, asking LOTS of questions. It was also good to see some young(er) people and some Delphi [insert a prehistoric version here] users who finally decided that they should upgrade.
If you want to see all the great new stuff in XE7, join me on Wednesday, 17th in Ljubljana. We’ll cover the new VCL stuff, multithreading support, improvements for multi-device development, business mobile services and more.
As usual, presentation will be in Slovenian language.
This is one of rare posts on my blog that doesn’t cover pascal programming. Proceed on your own risk ;)
For the last half a year, I’ve been a happy owner of a Chromecast device. Great stuff, especially as it allows me (with a small hack) to watch Netflix on my TV and listen to Pandora. At the beginning, it was a bit unstable, but through regular updates it stabilized quite a bit – until build 17977 got installed.
Since that time I got random crashes while playing any media (video or audio) from any source (in-house or external provider). It would load the player app, start playing, then crash after a few seconds. It would work fine for days, even weeks, but then it would start crashing and I would not be able to use for for half a day, after which it would start working again.
I’ve decided that the hardware is broken, maybe overheating, and I bought another one. (Did I mention it’s cheap?) But no luck – it started behaving the same as soon as it has upgraded to build 17977.
Few days ago I found a network forum thread where someone (sorry, no link, it got lost) mentioned a possibility of a bad power source. (My Chromecast is plugged into TV’s USB port.) And when the device started playing tricks on me today, I plugged it into an external USB power supply. And – surprise, surprise – it started working!
Something weird is still going on. When I start playing in a new player (i.e. when I switch apps), media is played for few seconds, then the TV goes blank and its power light starts blinking, then the picture reappears and media continues to play.
My current guess is that Chromecast does something weird which basically quick-resets the TV. When Chromecast was plugged into TV’s USB port, that also reset the Chromecast, but now that it’s plugged into an external power source, Chromecast continues playing while the TV does its yoyo trick.
I’m not completely satisfied with this solution as I would rather see my Chromecast to turn off together with the TV, but it is a “good enough” workaround. I still love that device, though. It’s the best stuff Google made in a long long time.
I’m posting this blog in hope that it will help other Chromecast users who may run into the same problem.
If you are still deciding whether to attend my workshop, you should hurry up. The organizers have notified me that there are only few places left as there are some physical constraints they have to observe, namely how many people fit in the conference room ;)
BTW, if you are interested in the parallel part of the workshop, you’ll be glad to know that I’ll also be covering the new cross-platform multithreading support in XE7.
DAPUG, the Database Application Programmers Users Group (aka Danish Embarcadero User Group) is one of Delphi user groups which organizes great events twice a year. I’m very proud that they have invited me to speak in October, even though I’ll miss ITDevCon because of that :(
(A note to ITDevCon organizers – DAPUG’s autumn workshop is traditionally organized near the end of October.)
First day will be completely dedicated to multithreading. We’ll start with basics – why and how – and proceed with TThread-based multithreading on all supported platforms. After lunch we’ll focus more on high-level multithreading with the open-sourced OmniThreadLibrary.
A note to participants: I’ll be presenting multiple small problems for you to solve during the workshop. At least you should have Delphi installed on the computer (for best experience it should be one of the latest versions). If you really want to come prepared, you can also preload OmniThreadLibrary and if you are trying for the best in class award ;) you can read all about high-level multithreading in advance on the OmniThreadLibrary wiki.
The second day will be organized around three topics – attributes, regular expressions and continuous integration. The common point is productivity – in the first two sessions I’ll be showing you how to use some of the incredible power of Delphi to simplify your programming life and in the latter I’ll be focusing on the last stage of any application – building and deploying the release version.
Workshop will be held on October 21st and 22nd in Hotel Hesselet in Nyborg.
More information and registration form can be found here.
If you need to write software for phones/browsers/node.js/microcontrollers, you should check out the new Smart Mobile Studio 2.1 (beta 1). The list of new and fixed features is much too long to list here so I’ll just focus on the most important additions.
A deceptively simple question – how do you update a progress bar from a ForEach loop – popped up on the Google+ OmniThreadLibrary community. The implementation turned out to be quite tricky so I created an example (55_ForEachProgress) which is now part of the OmniThreadLibrary SVN repository.
The starting point was a simple Parallel.ForEach loop which I further simplified in the demo.
procedure (const task: IOmniTask; const i: integer)
// do some work
// update the progress bar - how?
We cannot simply update the progress bar from the ForEach executor as that code executes in a background thread and one must never ever access VCL GUI from a background thread! It is also no good to send “please update” Windows messages to main thread as Parallel.ForEach is by default blocking – it waits for all workers to stop working – and messages won’t be processed during ForEach execution.
Yesterday I had to write a mapping from a set of radio buttons to an integer (and back). I couldn’t use TRadioGroup and so I had to iterate over controls to find out which one is checked. To do that, I used an enumeration helper which I wrote long time ago.
function TfrmColorRemappingDlg.GetMapping: integer;
Result := 0;
for ctrl in EnumControls(Self, TRadioButton) do
if TRadioButton(ctrl).Checked then
At that point I decided that this old-way enumeration is not good enough for the modern times. What I particularly dislike about it is that I know the type of objects enumerator will return (TRadioButton in this example) but I still have to cast the enumeration variable to that type. The solution is simple – use generics!
Besides being a programmer, I like taking pretty pictures (and working with wood, but that’s another story). And from time to time I like to print some pictures and hang them on a wall.
Because framing pictures is expensive and, frankly, most of them don’t deserve it, I like to print a “virtual frame” – a thin black border followed by a wide white border – around each photo. Until recently, I was adding them in some stupid program I found on the Internet (it doesn’t deserve to be named), but I was always having problems because you had to specify border width in pixels – and if I wanted to set the same border (for example, a 1,5 mm black border followed by a 20 mm white border) for a set of pictures in a different resolutions, I had to calculate pixel sizes for each photo, which was a pain.
So I sat down and wrote a border-adding program. It allows you to specify border sizes in “real” measures, it can process one picture or a folder full of them and it can add a suffix to processed pictures (plus it will skip files containing this suffix if they are found in the source folder) and that’s about it. It is small, simple, solves a real problem and – what I found the most impressing – I wrote it in a single working day. Truth to be told, I needed about a month of work – an hour here, 15 minutes there – but all together I needed less than eight hours. That is the power of Delphi!
If you have a need for such tool, go ahead and download it from my Dropbox. You can also get the source, which is released to a public domain (i.e., do with it whatever you want). It depends on few external libraries, which are all released with an open source license: JCL, JVCL, GpDelphiUnits, OmniXML. At the moment the GUI is written in VCL, because I really didn’t want to spend too much time on this project and I know VCL by heart, but if somebody wants to go ahead and rewrite it in FireMonkey, I certainly won’t stand in his/her way.
You cannot safe-cast a pointer. This will fail:
ptr as TProject
You can only cast pointers the unsafe way:
That is, unless you use this neat trick:
TObject(ptr) as TProject
This will also catch programming errors, specifically a pointer that doesn’t point to an object.