I have been toying with the idea of trying to convert the yajl parser bindings to Delphi in order to build a wrapper on top of the original C dll. yajl (Yet Another JSON Library) is a small fast SAX style JSON parser written and open sourced in C over at lloyd’s yajl GitHub page. I wanted to be able to use this library in particular because it’s very fast, small, portable and able parse from a stream. Plus, I had never really done any conversion of this nature on C header files before so I thought it might be a small, easy project to start with… I was a perhaps a little naive on this front!

I’ll leave you with a disclaimer early on: the code that I’ve been working on and have shared is not currently in a working state. This is the first part of my journey and I do intend on posting further as I learn from the major mistakes that I make in the process.

Approach

The 3 header files that I need to translate can be found in the src/api directory:

• yajl_common.h
• yajl_gen.h
• yajl_parse.h

I’m not sure what a *typical* process for conversion might look like but I started out by trying to use Dr Bob’s HeadConv tool as a way of getting me started and doing some of the legwork. However, the callback structure used by the parsing callbacks confused the tool and it never produced anything of use. After this setback I tried to install Rudy Velthuis‘s Conversion Helper Tool but I wasn’t able to load this into the Delphi 2009 IDE.

Having failed to get any of the conversion tools to do any of the work for me, I accepted my task and began to convert the headers from scratch. There were two resources that I found invaluable: the first is the Type Conversion table half way down the page on Dr Bob’s HeadConv page.  The second was the comprehensive Pitfalls of Conversion guide from Rudy.

As I began converting the headers I realised that although I thought I was translating the headers without a problem, the devil is in the detail and as my first major conversion project, I didn’t have the specfic knowledge necessary to correct my specific mistakes. As a result, please correct me if I have misunderstood any bits which I have picked up in the process.

Const parameters

One issue that I did notice is that there were quite a few parameters marked const in the header files, such as this declaration in yajl_parse:

   YAJL_API unsigned char * yajl_get_error(yajl_handle hand, int verbose,
                                            const unsigned char * jsonText,
                                            unsigned int jsonTextLength);

Rudy’s guide states that where possible Delphi programmers should ignore the const declaration as it’s easy to get wrong depending on whether the argument is passed by value or by reference, complicated by the issue that it means something subtly different in C. I translated this heading and simply ignored the const keyword:

    Tyajl_get_error = function(handle: yajl_handle;
                               verbose: integer;
                               jsonText: PChar;
                               jsonTextLegnth: Cardinal): PChar; stdcall;

Multiple Indirection Parameters

There was one declaration that I had to do a bit of searching for: it was in the yajl_gen file, in the declaration of yajl_gen_get_buf function:

YAJL_API yajl_gen_status yajl_gen_get_buf(yajl_gen hand,
                                              const unsigned char ** buf,
                                             unsigned int * len);

I had never seen the double asterisk before and found it surprisingly difficult to reliably Google for it. Luckily, this comprehensive page on C pointers was pretty useful in explaining that it is in fact a technique called multiple indirection which essentially creates a pointer to a pointer, in this case to a char.

    Tyajl_gen_get_buf = function (handle: Tyajl_gen;
                                 out buf: PChar;
                                 out len: Cardinal): yajl_gen_status; stdcall;

I wasn’t sure if this was indeed the correct translation but if you know otherwise then please let me know in the comments below.

Record Alignment and Enum size

When reading up on the perils of record alignment and enum sizes I found this blog post from Vlad loan Topan on Record Alignment and Enum sizes. Both problems are potentially applicable to the yajl header files. In his post, Vlad mentions that in order to line up the enum sizes you will need to use the {Z4} compiler directive to change the size from the Delphi default of 1 to the C compatible 4 as so:

type
  {$Z4}
  yajl_status = (
                  // no error was encountered
                  yajl_status_ok,
                  // a client callback returned zero, stopping the parse
                  yajl_status_client_canceled,
  ... snip ...

Reading through the Record alignment section of Rudy’s article I understood that I needed to search through the yajl project source to look for an Alignment setting. However, I couldn’t find a reference to the pragma directive anywhere in  the  source.

Next Steps

Well, it doesn’t actually work yet but I have put the Delphi-yajl project on GitHub where you can view my efforts so far, fork it and hopefully provide feedback or code contributions to show me where I’m going wrong. I have also setup a Delphi-yajl page here to serve as a placeholder for when it actually works!

Futher Reading

• yajl – The yajl project home page.
• Dr Bob’s Header Conversion Tool – The useful tool from the ever excellent Dr Bob.
• The Pitfalls of Conversion – Rudy Velthuis’s long but excellent article on commonly encountered problems when converting
• Conversion Helper Package – The Conversion package helper from Rudy but I’m uncertain as to how compatible it is any more.

Jim is planning another session for the DelphiLive conference (which I really wish I could go to, check it out if you haven’t already). However when running the last tournament we encountered a number of fatal bugs in the .NET UT3 Bot library which was originally put together by Andy Sterland & James Lissiak. As a result Jim and I had been discussing the idea of porting the original library to Delphi Prism so that we could fix a few of the more serious bugs, it would also allow potential Prism Developers who were not familiar with C# to dig into the library itself. This is a project conversion diary which will outline the approaches I tried, any hurdles I encountered and a few tips for trying to avoid them when converting your own project.

I started by running the C#ToOxygene Tool on all of the source files within the project, It’s a very simple and easy to use tool that as its name implies aims to convert C# source files to Delphi Prism files. I was able to run the tool without issue on every C# source file except for 3 where for some reason it exited producing the error:  ”Error during processing: Index was out of range” (Issue logged (rather clumsily) as #37).

Having started on the basics of the translation using the conversion tool to do the grunt work I then dived into the code with the Prism Wiki and MSDN C# documentation open to make a start on correcting the 600-odd errors that the resulting project produced upon an attempted Build.

At first glance I felt that the resultant code was a little bit visually “messy” in places and I felt it might be easier to prettify the code using a Code Formatter such as the JEDI Code Format tool to clean up the auto generated code and highlight any mismatched parenthesis or similar errors. However unfortunately the JEDI tool is not compatible with Prism and therefore refused to help me. If anyone knows of a Code Formatting tool which is compatible with Delphi Prism then please let me know in the comments below.

A few other issues which I encountered with the generated code or more generally are outlined below:

Internal Keyword

The C# internal (msdn doc) keyword was not correctly translated – for this I took a trip to the Prism Wiki and looked up the Class Member Visibility Levels page to find that the equivalent level assembly is listed there (Issue #42). Note that in Delphi Prism you can also have assembly or protected or assembly and protected depending upon whether you wish the class to be visible to descendants.

The C# “this” Keyword

The C# this. (msdn doc) keyword was not correctly translated to the Delphi Prism Self. equivalent that we’re all accustomed to. This isn’t hard to spot when going through the generated code and the issue had already been logged by Anton Kasyanov (Issue #39) and should be fixed shortly.

Float Types

One class made extensive use of the float type (msdn doc) which doesn’t exist as is a built-in type for Delphi Prism so you’ll need to convert it to one of the two Float types depending upon the precision you require.

Operator Overloading

Operator Overloading is not something that Delphi developers may be traditionally used to but Delphi Prism supports this nicely. However instead of using the sign operator that C# Developers use you’ll need to lookup the operator name and declaration on the Operator Overloading Wiki Page. eg. The Equals operator is declared as so:

class operator Equal(obj1, obj2: UTIdentifier): boolean;

Differences between return, Result and exit

This should be obvious to any C# Developer but it could be easy to forget about. Don’t forget that the return C# method (msdn doc) terminates execution of the method in which it is being executed and returns to the calling method and therefore be wary of using Result blindly in an identical manner, particularly with boolean statements that rely upon this fact. Eg. Consider the following C# Code:

public override bool Equals(object obj)
{
	if (obj is UTVector)
	{
		if (this._x == ((UTVector)obj)._x &&
			this._y == ((UTVector)obj)._y &&
			this._z == ((UTVector)obj)._z)
		{
			return true;
		}
	}
	return false;
}

Clearly, if you simply replace the return false; with Result := False; you will end up with a method that always returns False because the expression will always be executed no matter what Result is set to earlier in the method. In this case I simply moved the Result := false; to the top of the method. Delphi Prism also supports the Exit keyword which also allows you to Return a result parameter. This method is a lot closer to the C# return keyword and usage but the Exit page on the Prism Wiki warns against using too many exit keywords to avoid making the code harder to maintain.

Constructors are not named

This is a rare example of where the original C# code actually looks much closer to the end Delphi Prism code than a traditional Delphi programmer might think. In C# you might have a class and constructor that might look like this:

public class UTIdentifier
{
	internal UTIdentifier(string Id)
	{
	}
}

In Prism, we have nameless constructors which means that the equivalent Delphi Prism constructor implementation might look like this:

  constructor UTIdentifier(id: String);
  begin
  end;

It is important to note that in your class interface should adhere to this rule too. eg constructor(id: String);

This was something that the C#ToPas tool also generated incorrectly. (Issue #44)

Short-Circuit Boolean Expressions

I came across the C# || operator which performs a short-circuited OR boolean evaluation of the operands. I wasn’t sure that the Delphi Prism or operator produces the same behaviour but if I read the Expression Evaluation page correctly then I believe it does (In Delphi 2009, at least, this behaviour is set through the {$B+/-} compiler flag) .

Event Assignment

The Event Assignment routine for multicast delegate type events is slightly different in Delphi Prism from what we’re used to in Delphi Win32. Looking at the Event Assignment page in the wiki we can see that the actual method for assignment is much closer to the C# equivalent and uses the same C# += and -= operators. The C#ToPas tool converted this code a little too literally converted this C# code:

this._connection.OnDataReceived += new EventHandler(DataReceived);
this._connection.OnErrorOccurred += new EventHandler(ErrorOccurred);

to this:

Self._connection.OnDataReceived := Self._connection.OnDataReceived + new EventHandler(DataReceived);
Self._connection.OnErrorOccurred := Self._connection.OnErrorOccurred + new EventHandler(ErrorOccurred)

Which produces a compiler Error that Events in Delphi Prism don’t allow access to the underlying field. You should use the += operator instead as seen on the Wiki. (C#ToPas Issue logged as Issue #45).

UPDATE: I’ve just noticed (after logging my own issue) that the event assignment issue has already been reported and has been marked as Won’t Fix (Issue #27) so it looks like you’ll need to check _every_ event assignment in your project manually.

Switch and Case Statements

The C#ToPas tool did not appear to react well at all to use of the C# switch and case statements. I can’t give you any specific advice on how to fix these because each case statement was generated slightly differently in my converted code and therefore I can only advise that you check these manually or rewrite each of these methods by hand.

Reserved Keywords

Sadly this isn’t an issue that is related to the C#ToPas tool but more of an intrinsic difficulty when converting interoperable code between languages. I encountered at least one class that made use of a few reserved words in Delphi such as begin and end – I’m still not sure what to do with these for now.

Overall Impression

Despite a few early bugs the C#ToPas Tool is a good platform to begin converting your C# code to Delphi Prism although you may wish to ensure that you have some extensive Unit Tests for your code before the main code is converted so as to ensure that any bugs introduced can be picked up on quickly (which you have anyway right?). It is also worth noting that the Delphi Prism Wiki (which now authenticates via your CDN login) has excellent coverage and is an absolutely invaluable reference for anyone working with Delphi Prism.

By the time this entry is published I suspect that Carlo will be very close to fixing some or most of the above bugs in the C#ToPas tool.

The code is nowhere near complete yet and most of the files are still straight out of the Automatic conversion and therefore will not compile in any way but I’ve put what we have so far up on the rather smooth Github site at the PrismUT3RemoteBot project which anyone can fork and push changes back to. Git is a little strange to work with at first because it’s a different mindset to SubVersion/CVS but it’s worth checking out if you haven’t already.

[UPDATE: The Prism UT3 Remote Bot conversion project has been completed since this original post and may be used during Jim McKeeth's session at DelphiLive! Germany Sept 28 - Oct 2 2009.]

Ever since the release of Delphi.NET there has been much confusion surrounding why you would choose the Delphi language for .NET Development. When Delphi.NET was released there was concern that it was not a first class member of the .NET framework and always seemed to lag 12-18 months behind the lightning fast pace of development of the .NET Framework. With Prism Delphi offerings for .NET are based upon the RemObjects Oxygene compiler which isn’t required to maintain a loose language compatibility with the Win 32 Delphi compiler and therefore is able to progress at a much faster pace.  

Still, despite this: A recent Delphi Prism related thread at StackOverflow showed that there still seems to be a general feeling that Delphi is a second class citizen in the .NET Development World. Some even seemed to suggest that the language features in Prism make it unrecognisable as Delphi. To try to dispense with this idea: I thought that I would show off some of my own favourite new language features in Delphi Prism and ones which for me make it a natural fit for .NET.  

Please note: This is not intended to be a comprehensive guide to the new language features. For that you’ll need to refer to the Delphi Prism Wiki page on Compatibility with Win 32 Delphi.

My favourite new language features which Prism brings to the table for Delphi Developers is LINQ. Olaf Monien, who I also follow on Twitter (@omonien), posted a beautifully simple example of using LINQ with Delphi Prism on his own blog and then showed how Delphi Prism can also do LINQ to SQL. I have replicated his basic example below because it also demonstrates another great language feature.

// Type Declaration
  MusicAlbum = record
  public
    Name: string;
    Artist: string;
    AlbumYear: integer;
  end;

var
  MyAlbum: MusicAlbum;
  MyAlbums : List<MusicAlbum>;
begin
// Create our Album List
MyAlbums := new List<MusicAlbum>; 

// Setup a our records
MyAlbum := new MusicAlbum;
MyAlbum.Artist := 'Kanye West';
MyAlbum.Name := '808s and Heartbreak';
MyAlbum.AlbumYear := 2008;
MyAlbums.Add(MyAlbum);  

// Execute our LINQ Query
var AlbumsLastYear := from Album in MyAlbums where Album.AlbumYear.Equals(2008); 

// Add the result to our listbox
for Album in AlbumsLastYear do
begin
  lbFoundAlbums.Items.Add(Album.Artist + ' - ' + Album.Name + ' (' + Album.AlbumYear + ')');
end;

end;

 
This code clipping also demonstrates Type Inference which allows a variable type to be inferred from the context of it’s usage. For example, consider writing the following: var MyGreatList := new List<String>; or even something as simple as var s := ‘string’;. Type Inference is a useful addition which I can see myself making extensive use of. My only concern about Type Inference is how it affect’s the readability of the code as I am used to reviewing the var section of a method for a guide to what types are used within a method.

LINQ can also be used with XML. The below example takes our previous sample and reads the data from an XML file instead: 

<?xml version="1.0" encoding="UTF-8"?>
<albums>
		<album>
			<artist>Kanye West</artist>
			<title>808s and Heartbreak</title>
			<albumyear>2008</albumyear>
		</album>
		<album>
			<artist>Kanye West</artist>
			<title>Graduation</title>
			<albumyear>2007</albumyear>
		</album>
		<album>
			<artist>Nas</artist>
			<title>Unartistd</title>
			<albumyear>2008</albumyear>
		</album>
		<album>
			<artist>Notorious OST</artist>
			<title>The Notorious B.I.G.</title>
			<albumyear>2009</albumyear>
		</album>
</albums>

var
  AlbumData: XDocument;
begin
  // Load our XML Document with a System.Xml.Linq.XDocument
  AlbumData := XDocument.Load('../../albums.xml');

  // Query for albums in the year 2008
  var AlbumsLastYear := from Album in AlbumData.Descendants('album') where Album.Element('albumyear').Value = '2008' select Album;

  for Album in AlbumsLastYear do
  begin
    var s := String.Format('{0} - {1} ({2})', Album.Element('artist').Value, Album.Element('title').Value , Album.Element('albumyear').Value);
    lbFoundAlbums.Items.Add(s);
  end;

Another new language feature that I like in principle but will completely admit to not fully understanding yet is Anonymous Methods and Delegates which make executing code with different threads much easier. Sadly in my brief testing of Anonymous methods I discovered that they are only available in projects which link to the .NET Framework 3.0 and above (and, in my case, only WPF projects). In order to execute our ListBox adding code from the first code sample as an Anonymous Delegate you can do the following:

// Add the result to our listbox
for Album in AlbumsLastYear do
begin
  Dispatcher.Invoke(DispatcherPriority.ApplicationIdle, method(MyAlbum : MusicAlbum);
      begin
      lbFoundAlbums.Items.Add(MyAlbum.Artist + ' - ' + MyAlbum.Name + ' (' + MyAlbum.AlbumYear + ')');
      end, Album);
end;

This means that the compiler declares a delegate with a signature matching our anonymous method and we have now easily executed this code within a seperate thread with a minimum of code.

There are several new language features which I personally have no use for but which facilitate the use of the Microsoft Parallels framework such as Futures and Parallel sequences. Delphi Prism also supports Generics and as well as most of the standard Delphi Win32 syntax.
 
There are also lots of small additions that aren’t .NET features per-se but demonstrate the usefulness of freeing the Prism compiler and allowing more rapid progression such as Double Boolean Expressions. I’m sure we’ve all written a statement like this before: if (cost > 400) and (cost < 600) then. In Delphi Prism this can also be written as: if 400 < cost < 600 then.

As I quickly discovered whilst going through the Delphi Prism Wiki: the language changes to Delphi Prism were easier to adapt to and to learn than I had originally imagined. The New language features gained mostly did not affect my coding style too much so any developers who were concerned that Delphi Prism is nothing like Delphi have nothing to worry about. Many of the new features are useful for compatibility with the .NET Framework and will be a natural fit for existing Delphi or .NET Developers

The Easiest way to get started is to look at the free Oxidizer tool provided on the RemObjects Wiki. The tool helps with the conversion of Delphi Win32 projects to Delphi Prism (but I’m uncertain about how it performs on Delphi.NET to Delphi Prism). The Wiki is also an excellent place to get started, particularly the pages on Delphi Win32 vs Delphi Prism which list the major incompatibilities between the two languages. 

Whilst converting my Delphi.NET Library for accessing Twitter, I encountered a few basic hints and tips which I felt I should share here:

• You need to specify the namespace keyword at the top of your unit file instead of the unit keyword. The first time I tried to compile after doing this Prism still complained about not having a namespace keyword present, this was fixed by closing the solution and re-opening.
• Delphi Prism automatically makes classes that are not explicitly marked otherwise as strict private. This meant that I had to go through my library and mark all classes that I wanted to make public. eg. TMyClass = public class(System.Object);
• The overload keyword isn’t neccesary as overloading is now implicit. This isn’t a problem at all and isn’t dificult to fix as it simply meant doing a Search and Replace for the overload keyword and removing it.
• TObject no long exists and instead needs to be replaced with System.Object which has much the same properties. 
• I encountered a few problems with the use of for .. in loops. It would seem that Delphi Prism loop variables are local to the loop and therefore should be declared at the beginning of the loop (see the for wiki page for more info). In reality this meant changing: for strItem in list do to for strItem: string in list do and then removing the strItem: string; declaration in the method var section.
• The TObject.Create([...]); constructor still exists however it is now recommended that you switch to the new Object([..]) keyword for new projects. This may come as a shock to traditional Delphi’ers who have been .Create()‘ing since the dawn of Borland but this is the construction method that sems to fit in with the .NET framework better. There is also a compatibility flag in the Project properties which allows the compiler to work some magic to allow .Create to continue to function.

These are not the only changes that you will probably need to make but I found them to be a good starting point. You should definitely consult the Prism Wiki for help in which I was able to find answers very quickly (no wading boots required!).

Lastly: My project could do with a lot of refactoring in order to take advatages of the unique language features of Prism. This will take considerably more time as it means learning the new language features first!

A logo for homecamp, created by @ribotminimus

I spent all day last Saturday at Homecamp at the Electrical Engineering building at Imperial College London. Homecamp is effectively a hack-day about Home monitoring, home automation reducing energy and energy resource requirements in your home.

Previous to hearing of the day, I had become interested in these subjects because I had seen Andy Piper‘s Current Cost posts and the associated IBM’ers who had been doing some fantastic work on providing code libraries for accessing the Current Cost data. The CurrentCost unit is a great little electricity usage monitoring unit that is available to buy on eBay for about £40. Whilst a large amount of our discussion from that day did revolve around the CurrentCost unit, it was not the limit of our discussion in anyway (discussion around this was easy because it’s a cool little unit that is low-cost and easy to extract data from!).

The Day began with Dale Lane and Chris Dalby who had organised the day distributing name labels and wireless keys and asked us to give suggestions for sessions. We also had a quick word from James Govenor (@monkchips) who was generously sponsoring the event via his GreenMonk consultancy. 

The First talk of the day was from Andy Stanford-Clark who is a Master Inventor at IBM. As one might expect, Andy’s own house is a geeks dream (it even twitters!). Almost everything that can be is monitored and automated, even to the mouse traps that are set in his loft which text him or his family when a mousetrap is set off or the cheese used as bait has gone off. He measured his water usage by requesting a new meter which had a magnetised needle, thus allowing him to setup a device which gets a signal every time the needle rotates. Andy was also a big advocate of the MQTT protocol which he uses for client projects with IBM and as the central messaging service for his house works. MQTT is a Publish-Subscribe protocol which makes it ideal for things like the house networks that we were talking about. He also mentioned the use of X10 and ZigBee in controlling almost device or system in the house. You can see Andy’s full talk in the video that Andy Piper made.

Photo credit: Andy Piper

Joe Short and Phoebe Bright then did a talk on Dynamic Demand. This is essentially about smoothing out the hour by hour and minute by minute variations in power demands on the national grid. This is important becuase peak time power requirements mean that power companies have to bring very expensive and very environmentally damaging types of power generator online. We discussed about how this requires social change and we discussed dynamic energy pricing as a method of bringing about this change. In Italy for example the government required dynamic pricing smart meters to be installed in every house. This means that people are rewarded for putting their tumble dryer (if you needed a tumble dryer in a hot country like italy!) on at 3am in the morning when electricity is considerably cheaper. The general message here seemed to be that we have limited scope for activity here until we can push suppliers for dynamic pricing. This will take some time but once this is done, you can for example program washing machines to automatically start when the national price of electricity is at it’s cheapest throughout the day (very cool).  

Dale Lane took us through some of the ways in which the IBM Hursley users of the CurrentCost units have been trying to address the social aspects of getting people to use less electricity. They have been working on a realtime site for sharing and contrasting data from their units and would like to start creating some XBox live style point scoring awards. This would mean awards for biggest 1 day improvement or lowest house rest point. 

We also had a talk from Nicholas O’Leary who gave an interesting talk about the potential for Arduino use in the home. The Arduino is an open-source electronics platform that allows the flexibility to program and build low cost sensor inputs (light, heat, magnetic etc) to interact with a number of outputs. Nick showed us an ambient orb that he had built to show the amount of power his house is using at that particular moment. It glows green, yellow or red depending on whether the house electricity usage falls within certain limits. You can buy arduino units and shields from a number of sources but I am planning on getting a starter kit which should be back in stock soon at tinker.it. 

There was discussion in both Andy’s talk and Nick’s talk about how you could end up consuming more power by measuring and monitoring your home by the time you’ve got a server plugged into all manner of electrical monitoring devices. We discussed the Viglen MPC-L device which runs on a rediculously small amount of electricity usage (there was some discussion of costing you approx £10 per year on electicity usage). The Arduino can be powered with a normal 9V battery.

We also had a presentation from the Patchube (Patch-U-Bay) folks who were explaining about how you can get data in to the site and the various ways you use and share that information. I could see a lot of potential for this site but first I need to generate some data to share!

Photo Credit: Andy Piper

Overall I had a very inspiring day and met some extremely interesting people from all manner of backgrounds, interests and areas. It was nice to meet so many people who I had interacted with on Twitter and some who I had never met before but whom I shall certainly be looking forward to meeting again soon. I will be ordering all sorts of kit to play with as a result of the talks given at Homecamp and so the day will almost certainly cost me a lot of money in gadgets and time in the future but at least I will have a lot of fun doing it! The first thing I will be doing is writing a native Delphi library for the CurrentCost unit and contributing that to the Google Code Repository. There is another Homecamp planned for March which I hope that I will be around for again and this time able to contribute some ideas and projects towards it.

Thank-you to Chris Dalby, Dale Lane and James Governor for their work in setting up the day and to everyone who presented or otherwise contributed to the day. I can’t wait to share what I do as a result of the inspiration that the first day gave me!

Delphi Prism was announced finally at the Microsoft PDC where we discovered (or some of us) that Delphi Prism is the new Delphi .NET Development solution which drops the slightly crippled compatibility approach that Delphi used to employ and instead fits within the Visual Studio IDE. Delphi Prism now supports all the latest and greatest .NET technologies including WPF, LINQ and Various Language methods. They’ve achieved this by making use of the extremely cool RemObjects Oxygene Compiler which I would highly recommend that you investigate right away if you’re interested at all in .NET Development! I will be doing a post soon to discuss some of my favourite new Delphi Prism language features!

This rejuvenation of Delphi is causing a product marketing effect and is slowly gathering momentum and I fully intend on doing whatever I can to generate enthusiasm for the Delphi Programming Community. This concept of User-led marketing has been widespread for many years as Apple fans will testify. As part of this I have a new project in mind for the Delphi community and will be explaining this in due course. I will certainly require Delphi enthusiasts to help with this venture, if you’re interested then please contact me.