To content | To menu | To search

Tag - Delphi

Entries feed

2015, Saturday November 21

Try to avoid RTTI (ab)use

There is a very trendy move, since a few years, to value so called "meta-programming".
In short, it is about the ability to treat programs as their data.
It is a very powerful paradigm in functional languages, and it was also introduced to OOP languages, even in SmallTalk a long time before this concept was trendy in Ruby, C# or Java.

In OOP compiled languages, reflection is used to achieve a similar behavior at run-time, mainly via RTTI (Run-Time Type Information).
Delphi supports RTTI since its version 1, as it was heavily used e.g. for all UI streaming.
In our framework, we rely on RTTI for its main features: ORMSOA and MVC - and even in some other parts, like Desktop UI generation.

But RTTI could easily be abused.
Here are some thoughts, started as a comment in a good old Mason's blog article about how RTTI performance may be a bottleneck.
My comment was to get rid of RTTI, and follow a SOLID implementation with explicit OOP code, like use of interface.

Continue reading...

2015, Tuesday November 17

Benefits of interface callbacks instead of class messages

If you compare with existing client/server SOA solutions (in Delphi, Java, C# or even in Go or other frameworks), mORMot's interface-based callback mechanism sounds pretty unique and easy to work with.

Most Events Oriented solutions do use a set of dedicated messages to propagate the events, with a centralized Message Bus (like MSMQ or JMS), or a P2P/decentralized approach (see e.g. ZeroMQ or NanoMsg). In practice, you are expected to define one class per message, the class fields being the message values. You would define e.g. one class to notify a successful process, and another class to notify an error. SOA services would eventually tend to be defined by a huge number of individual classes, with the temptation of re-using existing classes in several contexts.

Our interface-based approach allows to gather all events:

  • In a single interface type per notification, i.e. probably per service operation;
  • With one method per event;
  • Using method parameters defining the event values.

Since asynchronous notifications are needed most of the time, method parameters would be one-way, i.e. defined only as const - in such case, an evolved algorithm would transparently gather those outgoing messages, to enhance scalability when processing such asynchronous events. Blocking request may also be defined as var/out, as we will see below, inWorkflow adaptation.

Behind the scene, the framework would still transmit raw messages over IP sockets (currently over a WebSockets connection), like other systems, but events notification would benefit from using interfaces, on both server and client sides.
We will now see how...

Continue reading...

2015, Friday October 23

Letters of Hope

As we already notified in this blog, Embarcadero has been finally bought by IDERA.

Delphi users received a letter from Randy Jacops, IDERA CEO.
Written in my mother language, in perfect French. Nice!

The letter states that they have 20,000 customers...
It sounds more realistic than the numbers usually given for Delphi "users".
Even if it counts for all their tools.

In our forums, we have 1,384 registered users (real humans: we do not accept bots via a Turing test during registration).
It sounds like if Open Source projects are able to gather a lot of users.
And certainly because we maintain support from Delphi 6 up to Seattle (and even Delphi 5 for some part of our libraries)... we have for sure users using FPC/Lazarus (which we also started to support), and others which did not upgrade to the latest Delphi version!

In Randy's letter, the community has a special place.
I hope future of Delphi would see Open Source projects brought by the community as a chance, not as competition.

I'm currently working on a cloud of mORMot servers, serving content coming from high numbers of connected objects.
Object Pascal powered servers, under Windows or Linux (with FPC), are working 24/7 with very low resource use.
A lot of BigData stream is gathered into MongoDB servers, following the CQRS pattern.
It is so easy to deploy those servers (including their high performance embedded SQlite3 database), that almost everyone in my company did install their own "cloud", mainly for testing purpose of the objects we are selling...
Real-time remote monitoring of the servers is very easy and integrated. You could even see the log changing in real-time, or run your SQL requests on the databases, with ease.
When I compare to previous projects I had to write or maintain using Java or .Net, I can tell you that it is "something else".
The IT administrators were speechless when they discovered how it worked: no need of containers, no need of virtual machines (but for infrastructure needs)...
The whole stack is SOA oriented, in an Event-Driven design (thanks to WebSockets callbacks). It follows DDD principles, thanks to the perfect readability of the object pascal language.
Delphi, and Open Source, could be great to create Internet Of Things servers...

2015, Monday October 5

Delphi 10 Seattle Win64 compiler Heisenbug: unusable target

Andy reported that he was not able to validate its IDE fix pack for Delphi 10 Seattle, due to its Win64 compiler not being deterministic anymore.
The generated code did vary, from one build to other.

Sadly, on our side, we identified that the code generated by the Win64 compiler of Delphi 10 Seattle is broken.
We have observed some weird code generation with the Win64 platform as a target. Some unexpected exception do occur (like a EPrivilege or EAccessViolation exception).
But it is a random issue, very difficult to reproduce.  After a recompile, no problem any more. Or a problem at another place... A typical Heisenbug...
And, to be clear, no such problem when using an older version of Delphi...

We hope that the corresponding QC entry would be quickly fixed.
So we will stay away from Delphi 10's Win64 compiler, and use Delphi XE8 instead, in the meanwhile.

Update: Issue fixed!
Allen Bauer recognized that "It was an uninitialized memory allocation" in the QC, and that he is pushing to include the fix into the upcoming Seattle 10 Update 1.
Nice seeing such a quick reaction. Delphi is not dead, even if Embarcadero was just acquired! :)

2015, Monday September 28

mORMot show case: Illustrated Spare Parts Catalog

Illustrated Spare Parts Catalog is, as its name suggests, a software for creating and publishing spare parts catalogs.
It uses mORMot for client-server communication and ORM, and SynPdf for the reporting.

Sounds like a powerful solution.
It is also a testimony that you could use big databases (20 GB of blobs) with a SQlite3 engine, and access them via REST using mORMot, without the hassle of setting up a regular RDBMS.

If you (or Google Translate or via this direct link on know a little of Russian, it is worth reading this previous blog article, about how the software author interacted with our Open Source project.
In fact, Chaa did provide a lot of feedback, patches and new features (like direct authentication via Active Directory).
Open Source could be great!

Thanks Chaa for the feedback, and interest!

2015, Friday September 25

ORM TNullable* fields for NULL storage

In Delphi code, NULLable types do not exist as such. There is no native int? type, as in C#.
But at SQL and JSON levels, the NULL value does exist and should be converted as expected by the ORM.

In SQLite3 itself, NULL is handled as stated in (see e.g. IS and IS NOT operators).
It is worth noting that NULL handling is not consistent among all existing database engines, e.g. when you are comparing NULL with non NULL values... so we recommend using it with care in any database statements, or only with proper (unit) testing, when you switch from one database engine to another.

By default, in the mORMot ORM/SQL code, NULL will appear only in case of a BLOB storage with a size of 0 bytes.
Otherwise, you should not see it as a value, in most kinds of ORM properties.

Null-oriented value types have been implemented in our framework, since the object pascal language does not allow defining a nullable type (yet)

We choose to store those values as variant, with a set of TNullable dedicated types, as defined in mORMot.pas:

  TNullableInteger = type variant;
  TNullableBoolean = type variant;
  TNullableFloat = type variant;
  TNullableCurrency = type variant;
  TNullableDateTime = type variant;
  TNullableTimeLog = type variant;
  TNullableUTF8Text = type variant;

Continue reading...

2015, Monday September 21

Embarcadero bought by Idera

Just a link found on Internet.

Jefferies is also leading a US$425m covenant-lite credit to back Idera's acquisition of Embarcadero Technologies. Idera is backed by TA Associates. The deal, which launches on Thursday, includes a US$25m revolving credit, a US$300m first-lien term loan and a US$100m second-lien term loan.

Perhaps some company name change!
I wonder what it may lead for Delphi's future. May be some time to "optimize" the acquisition, and "manage" a new line of products.
But if Embarcadero is worth buying, it means that Delphi's is worth betting on!

They may find out that they should focus on the compiler stuff, and that Open Source is a chance, not a competitor.

2015, Thursday September 17

AVAST did detect ALL Delphi programs as dangerous

Today, an avalanche of "false postitive detection" of AVAST heuristic engine did occur.
Any executable built with Delphi XE8 or Delphi 10 Seattle was identified as a Win32:Banker-MGC [Trj] threat!

Heuristic analysis is a method employed by many computer antivirus programs designed to detect previously unknown computer viruses, as well as new variants of viruses already in the "wild".

Continue reading...

2015, Wednesday September 16

Feedback from the Wild

We just noticed a nice feedback from a mORMot user.

Vojko Cendak commented the well-known DataSnap analysis based on Speed & Stability tests blog article written by Roberto some months years (!) ago.
It is not meant to be the final word, perhaps there was some tuning possible for RTC (which is told to be very reliable), but it is worth a look:

We used 3 products: RO, RTC and Mormot.. I won’t speak about RO ( slow and heavy ). We tried RTC but was too very slow and CPU consuming in getting lots of 1000 .. 5000 dynamically fetching OPC tags (let’s say list of small objects) – at least once per second (one client). I mean Mormot is FAST and we’re glad to be so. We use Mormot in actual productions 24/7 on several sites: servers don’t even blink on client requests and run smoothly and reliably.

Thanks for the kind words!
We have a lot of feedback, around the world, from users of our little Open Source project, very happy with its abilities.
We try to make it always better! Open Source, and Delphi as a platform, do rock!

2015, Monday September 14

Performance issue in NextGen ARC model - much better now

Back in 2013, I found out an implementation weakness in the implementation of ARC weak references in the RTL.
A giant lock was freezing all threads and cores, so would decrease a lot the performance abilities of any ARC application, especially in multi thread.

I just investigated that things are now better.

Continue reading...

2015, Monday August 31

Delphi 10 = DX Seattle is out, mORMot supports it

We expected Delphi XE9, and now we have Rad Studio 10 Seattle, with Delphi renamed as Delphi 10 Seattle, or simply DX.

No big news for the Delphi compiler itself (we are still waiting for Linux server support), but a lot of FireMonkey updates, Windows 10 compatibility enhancements, enhancements to JSON (better performance using a SAX approach), and NoSQL/MongoDB support in FireDAC.
The documentation is rather sparse for the new features, but it goes into the right direction (we support MongoDB since a long time, in our ORM/ODM).
See what's new in details.

Of course, our Open Source mORMot framework supports this version.
Feedback is welcome, as usual!
Enjoy the new DX IDE!

2015, Monday August 24

Introducing Delphinus PackageManager

You may have missed the news.
So I relay here the information from Delphinus PackageManager blog article.

Delphinus is a new Package Manager, which runs on Delphi XE and newer, directly from within your IDE.
It is GitHub-based, and fairly easy to add a reference to.

Of course, I tried to add mORMot to the list. We were the first external project linked in!
In contrast to GetIt (which rejected mORMot to be part of it - as we expected), it is very open-minded.

We wish great success to this project, which sounds Open and Efficient!

2015, Sunday August 23

"SQL and NoSQL", not "SQL vs NoSQL"

You know certainly that our mORMot Open Source framework is an ORM, i.e. mapping objects to a relational / SQL database (Object Relational Mapping).
You may have followed also that it is able to connect to a NoSQL database, like MongoDB, and that the objects are then mapped via an ODM (Object Document Mapping) - the original SQL SELECT are even translated on the fly to MongoDB queries.

But thanks to mORMot, it is not "SQL vs NoSQL" - but "SQL and NoSQL".
You are not required to make an exclusive choice.
You can share best of both worlds, depending on your application needs.

In fact, the framework is able to add NoSQL features to a regular relational / SQL database, by storing JSON documents in TEXT columns.

In your end-user code, you just define a variant field in the ORM, and store a TDocVariant document within.
We also added some dedicated functions at SQL level, so that SQLite3 could be used as embedded fast engine, and provide advanced WHERE clauses on this JSON content.

Continue reading...

2015, Saturday August 15

Breaking Change in mORMot WebSockets binary protocol

Among all its means of transmission, our mORMot framework features WebSockets, allowing bidirectional communications, and interface-based callbacks for real time notification of SOA events.
After several months of use in production, we identified some needed changes for this just emerged feature.

We committed today a breaking change of the data layout used for our proprietary WebSockets binary protocol.
From our tests, it would increase the performance and decrease the resource consumption, especially in case of high number of messages.

Continue reading...

2015, Tuesday July 14

New blog about mORMot

An enthusiastic mORMot user, named willo in the forum, just started a blog about his experiments with our framework.

The information there is clear, simple, and right to the point.
If you are a little lost in our huge documentation, it is a good place to start!

Continue reading...

2015, Tuesday June 30

Faster String process using SSE 4.2 Text Processing Instructions STTNI

A lot of our code, and probably yours, is highly relying on text process.
In our mORMot framework, most of its features use JSON text, encoded as UTF-8.
Profiling shows that a lot of time is spent computing the end of a text buffer, or comparing text content.

You may know that In its SSE4.2 feature set, Intel added STTNI (String and Text New Instructions) opcodes.
They are several new instructions that perform character searches and comparison on two operands of 16 bytes at a time.

I've just committed optimized version of StrComp() and StrLen(), also used for our TDynArrayHashed wrapper.
The patch works from Delphi 5 up to XE8, and with FPC - unknown SSE4.2 opcodes have been entered as hexadecimal bytes, for compatibility with the last century compilers!
The resulting speed up may be worth it!

Next logical step would be to use those instruction in the JSON process itself.
It may speed up the parsing speed of our core functions (which is already very optimized, but written in a classical one-char-at-a-time reading).
Main benefit would be to read the incoming UTF-8 text buffer by blocks of 16 bytes, and performing several characters comparison in a few CPU cycles, with no branching.
Also JSON writing would benefit for it, since escaping could be speed up thanks to STTNI instructions.

Any feedback is welcome, as usual!

2015, Sunday June 21

Why FPC may be a better compiler than Delphi

Almost every time I'm debugging some core part of our framework, I like to see the generated asm, and trying to optimize the pascal code for better speed - when it is worth it, of course!
I just made a nice observation, when comparing the assembler generated by Delphi to FPC's output.

Imagine you compile the following lines (extracted from SynCommons.pas), to convert some number into ASCII characters:

c100 := val div 100;
PWord(P)^ := TwoDigitLookupW[val];

This divides a number by 100, then computes the modulo in val, to store two digits at a time. We did not use val := val mod 100 here, since mod would do another division, so we rely on a simple multiplication to compute the modulo.
You may know that for today's CPUs, integer multiplication is very optimized, taking a cycle (or less, thanks to its pipelines), whereas a division is much more expensive - if you have some spare time, take a look at this document, and you will find out that a div opcode could use 10 times more cycles then a mul - even with the latest CPU architectures.
Let's see how our two beloved compilers do their homework (with optimization enabled, of course)...

Delphi generates the following code for c100 := val div 100:

005082AB 8BC1             mov eax,ecx
005082AD BE64000000       mov esi,$00000064
005082B2 33D2             xor edx,edx
005082B4 F7F6             div esi

Whereas FPC generates the following:

0043AC48 8b55f8                   mov    -0x8(%ebp),%edx
0043AC4B b81f85eb51               mov    $0x51eb851f,%eax
0043AC50 f7e2                     mul    %edx
0043AC52 c1ea05                   shr    $0x5,%edx
0043AC55 8955f0                   mov    %edx,-0x10(%ebp)

Even if you are assembler agnostic, and once you did get rid of the asm textual representation (Delphi uses Intel's, whereas FPC/GDB follows AT&T), you can see that Delphi generates a classic (and slow) div esi opcode, whereas FPC uses a single multiplication, followed by a bit shift.

This optimization is known as "Reciprocal Multiplication", and I would let you read this article for mathematical reference - or this one.
It multiplies (mul) the number by the power of two reciprocal of 100 (which is the hexadecimal 51eb851f value), followed by a right shift (shr) of 5 bits.
Thanks to 32 bit rounding of the integer operations, this would in fact divide the number per 100.
Even it consists in two assembler opcodes, a mul + shr is in fact faster than a single div.

It is a shame that the Delphi compiler did not include this very common optimization, which is clearly a win for some very common tasks. 

Of course, the LLVM back-end used on the NextGen compiler can do it, be we may expect this classic optimization be part of the decades-old Delphi compiler.
And I'm still not convinced about the performance of the NextGen generated code, since the associated RTL is known to be slow, so won't benefit of LVVM optimization - which takes  a LOT of time to compile, by the way (much more than FPC).

Congrats, FPC folks!

2015, Tuesday June 16

Handling Cross-Platform Time Zones

One common problem when handling dates and times, is that time is shown and entered as local, whereas the computer should better use non-geographic information - especially on a Client-Server architecture, where both ends may not be on the same physical region.

A time zone is a region that observes a uniform standard time for legal, commercial, and social purposes.
Time zones tend to follow the boundaries of countries and their subdivisions because it is convenient for areas in close commercial or other communication to keep the same time.
Most of the time zones on land are offset from Coordinated Universal Time (UTC) by a whole number of hours, or minutes.
Even worse, some countries use daylight saving time for part of the year, typically by changing clocks by an hour, twice every year.

The main rule is that any date and time stored should be stored in UTC, or with an explicit Zone identifier (i.e. an explicit offset to the UTC value).
Our framework expects this behavior: every date/time value stored and handled by the ORM, SOA, or any other part of it, is expected to be UTC-encoded.
At presentation layer (e.g. the User Interface), conversion to/from local times should take place, so that the end-user is provided with friendly clock-wall compatible timing.

As you may guess, handling time zones is a complex task, which should be managed by the Operating System itself.
Since this cultural material is constantly involving, it is updated as part of the OS.

In practice, current local time could be converted from UTC from the current system-wide time zone. One of the only parameters you have to set when installing an Operating System is to pickup the keyboard layout... and the current time zone to be used. But in a client-server environment, you may have to manage several time zones on the server side: so you can't rely on this global setting.

One sad - but predictable - news is that there is no common way of encoding time zone information.
Under Windows, the registry contains a list of time zones, and the associated time bias data. Most POSIX systems (including Linux and Mac OSX) do rely on the IANA database, also called tzdata - you may have noticed that this particular package is often updated with your system.
Both zone identifiers do not map, so our framework needed something to be shared on all systems.

Continue reading...

2015, Saturday June 6

GetIt "Spirit" Concerns

I'm confused by the GetIt Submitting official blog page.
Reminds me the darker ages of Delphi licensing change of XE3.

GetIt is the new XE8 package manager for RAD Studio. Information about how to submit your libraries to GetIt has just been made available by Embarcadero. The idea behind GetIt is really to make is easier and faster to discover, install, and keep updated some of the best open source libraries for Delphi and C++Builder.

When you look at the approval conditions, it sounds like if mORMot would not find its way in this package manager:

Replacing key capabilities that are part of the core platforms definitions such as Client/Server FireDAC pack or the DataSnap/EMS Enterprise middleware, would be less likely to be accepted.
The different SKUs are meant for different types of developers, and multi-tier capabilities with strong client/server RDBMS integration require an Enterprise edition license.
We will bias acceptance toward GetIt libraries that respect the spirit of our licensing and editions, not just use the letter of the license and the technical boundaries. If you are unsure about your submission please check with us first. 

What is this "spirit of our licensing and editions"?
Why is it not part of the official license terms?
Where does this assumption comes from?
Would the licensing conditions change in the close future, as with the XE3 "episode"?
Would Marco's interpretation become the new rule?

It clearly reminds me the XE3 time where there was an attempt from Embarcadero to modify their licence terms, so that third party vendors or Open Source libraries would not be allowed to create multi-tier frameworks with Delphi!
Is it true that "strong client/server RDBMS integration require an Enterprise edition" ?
Last time I checked the licence terms, it was not stated.
Why on earth would we have to pay for the Entreprise edition, if the Professionnal edition is all that you need?

Still the same "closed" spirit.
It is like if they know their own n-Tier solution weaknesses, so they try to avoid any other possibility, but to use their own.
They clearly do not understand the benefit and dynamic of Open Source.

I guess our little mORMot falls directly into this "unwelcomed" category.
I did not make the submission yet. But should I?
Perhaps sub-part of the framework may find its way in: SynPdf, SynCrypto, SynGdiPlus, SynCommons...
But the main ORM/SOA/REST/MVC/StubMock features would certainly be rejected.

Our Open Source project is sometimes preferred to DataSnap/EMS (or even FireDAC), not only for licence cost, but also about features, documentation, stability, compatibility with older versions of Delphi, performance, and Linux compatibility.
I have encountered several companies which are still using Delphi because of mORMot: if they did not have found it, they would have moved to C# or Java, just to be able to use a full SOA/MVC stack, which was not available, even in the "Enterprise" version of Delphi.

Story repeats itself.
I just wanted to ensure that the licensing terms would not change in that direction.
I - as many Delphi users - would not let this GetIt "spirit" become the new rule.
We have to react, as we did for XE3, otherwise we may all suffer!
IMHO Embacardero should better focus on the compiler and IDE, not cutting the branch on which they are seated...

What do you think? Comments and feebacks are welcome!

2015, Monday June 1

Updated Slides about ORM SOA MVC SOLID DDD

One year ago, we published a set of slides about the main concepts implemented by our framework.
Mainly about ORM (and ODM), NoSQL, JSON, SOA, MVC (and MVVM), SOLID, DDD, CQRS and some patterns like Stubs, Mocks, Factory, Repository, Unit-Of-Work.
Worth a look, if you want to find out the benefits of the latest software development techniques.
They try to open the landscape of any Delphi developer (probably with a mostly RAD and OOP background) to some new areas.

I just updated the slides from our public GoogleDrive folder.
They now reflect the latest state of the framework (e.g. ORM real-time synchronization, asynchronous callbacks, DDD CQRS services...).
They have also been polished after several public presentations, since I used them as base for trainings I made for some European companies.

If you want to go further, or have some more enlightenment, ensure you took a look at our framework Documentation, which would detail all those patterns, and how mORMot may help implementing them for your projects!

Feedback is welcome on our forum, as usual!

- page 1 of 15