Synopse Open Source

In order to enhance code modularity, we extracted logging and testing features from SynCommons.pas. Discover the new SynLog.pas and SynTests.pas units! Documentation has been updated to reflect the changes. This is a breaking change... Ensure you add SynLog and/or SynTests to your uses clauses, just  […]

For pre-Unicode versions of Delphi, the unique way of having UTF-16 native type is to use the WideString type.
This type, under Windows, matched the BSTR managed type, as used by OLE and COM components.

In Delphi, WideString implementation calls directly the corresponding Windows API, and do not use the main Delphi heap manager.
Even if since Vista, this API did have a huge speed-up, it is still in practice much slower than the regular string type. Problems is not about UTF-16 encoding, but about the memory allocation, which is shared among processes, using the Windows global heap, and is much slower than our beloved FastMM4.
Newer versions of Delphi (since Delphi 2009) feature a refactored string = UnicodeString type, which relies on FastMM4 and not the Windows API, and is much faster than WideString.

Within our mORMot framework, we by-passed this limitation by using our RawUTF8 type, which is UTF-8 encoded, so as Unicode ready as the new UnicodeString type, and pretty fast.
In a recent internal project, we had to use a lot of WideString instances, to support UTF-16 encoding in Delphi 7/2007, involving a lot of text.

It sounded to be very slow, so we had to do something!

This is where our new SynFastWideString unit comes in.

Purpose of this unit is to patch the system.pas unit for older versions of Delphi, so that WideString memory allocation would use FastMM4 instead of the slow BSTR Windows API.
It will speed up the WideString process a lot, especially when a lot of content is allocated, since FastMM4 is much more aggressive than Windows' global heap and the BSTR slow API. It could be more than 50 times faster, especially when releasing the used memory.
The WideString implementation pattern does NOT feature Copy-On-Write, so is still slower than the string UnicodeString type as implemented since Delphi 2009. This is the reason why this unit won't do anything on Unicode versions of the compiler, since the new string type is to be preferred there.

Mustache is a well-known logic-less template engine.
There is plenty of Open Source implementations around (including in JavaScript, which can be very convenient for AJAX applications on client side, for instance).
For mORMot, we created the first pure Delphi implementation of it, with a perfect integration with other bricks of the framework.

In this second part of this series of blog articles, we will introduce the Mustache syntax.
You can download this documentation as one single pdf file.

By default, both GDI+ anti-aliased drawing and PDF file generation using our libraries did lack of font-fallback implementation.

If some of the characters in a string are not supported in a requested font, they were drawn as square symbols on the GDI+ canvas or the PDF content.

The font-fallback mechanism implemented will use a third-party font (Arial Unicode MS by default, which is installed with Microsoft Office), for any glyph that are missing when rendering the content. Of course, for PDF generation, you are able to embed the font within the generated file (this is by the way mandatory for PDF/A-1 format).

Both of these new features are handled by the SQlite3Pages unit, i.e. for report anti-aliased drawing preview and PDF generation.

By the way, the TGDIPages class itself (the one used for report generation from code) now handles by default Unicode text, even with Delphi versions prior to 2009 (via the SynUnicode string type, which maps WideString before Delphi 2009, then UnicodeString starting with Delphi 2009). Does make sense with such a font-fallback mechanism.

Our SynDBExplorer free tool has been enhanced. A SQL request history has been added to the software. It is now able to handle directly Jet / MSAccess .mdb files. It has also several fixes included (including Oracle direct link), and the internal SQLite3 engine has been updated to its latest  […]

We already shipped a sophisticated set of logging classes some month ago.

Since then, its features have been enhanced, and the system has been deeply interfaced with our main ORM framework. Now almost all low-level or high-level operations can be logged on request.

But since the log files tend to be huge (for instance, if you set the logging for our unitary tests, the 6,000,000 unitary tests creates a 280 MB log file), a log viewer was definitively in need.

Logging is everything... unless you never wrote a bug in your program!

Let us introduce a new logging class:

• logging with a set of levels;
• fast, low execution overhead;
• can load .map file symbols to be used in logging;
• compression of .map into binary .mab (900 KB -> 70 KB);
• inclusion of the .map/.mab into the .exe;
• reading of an external .map to add unit names and line numbers to a log file without .map available information at execution;
• exception logging (Delphi or low-level exceptions) with unit names and line numbers;
• optional stack trace with units and line numbers;
• methods or procedure recursive tracing, with Enter and auto-Leave;
• high resolution time stamps, for customer-side profiling of the application execution;
• set / enumerates / TList / TPersistent / TObjectList / TContainer / dynamic array JSON serialization;
• per-thread or global logging;
• multiple log files on the same process;
• integrated log archival (in zip or any other format);
• Open Source, works from Delphi 6 up to XE.

We just released a new unit to the source code repository.

It's a simple, small and compact MM, built on top of the main Memory Manager(FastMM4 is a good candidate, standard since Delphi 2007), architectured in order to scale on multi core CPU's (which is what FastMM4 is lacking).

Original code is ScaleMM - Fast scaling memory manager for Delphi by André Mussche.

In our Source Code repository you would have perhaps noted the SynLZ.pas and SynLZO.pas units.

These are two in-memory compression units, optimized for speed.

SynLZ is a brand new LempelZiv-based compression algorithm, the fastest around for compression speed, so very suitable for using on Server side, with very low CPU consumption.