The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 4,262 other subscribers

Archive for June 13th, 2018

Build 2018: The Future of C#

Posted by jpluimers on 2018/06/13

A cool preview of things to come in C# 8: [WayBackBuild 2018: The Future of C#

Via: [WayBack] C# 8 changes, exemplified #csharp – Lars Fosdal – Google+

–jeroen

Posted in .NET, C#, Development, Software Development | Leave a Comment »

Delphi, IBX and the Turkish I problem

Posted by jpluimers on 2018/06/13

Last year, it took a while to reproduce and it is likely not fixed anytime soon: if you use Delphi and IBX (InterBase Express) to connect to either InterBase or FireBird database, then in the Turkish locale do not use lowercase SQL in your Delphi code as it will break on the

I’ve decided to put this in a separate post than the one I discovered the issue in as that one focused on the Unicode and language background of the various i/I/ characters and this post on the Delphi part.

So for the non-Delphi part, read Source: Field “id” not found and the The Turkish-İ/I/i/ı and case conversion – Update on the dasBlog Turkish-I bug and a reminder to me on Globalization – Scott Hanselman.

More recently, I learned that the same problem also happens in the Azeri language or Azerbaijani language – Wikipedia via [WayBack] SQL Instance Collation – Language Neutral Required:

uppercase / lowercase mappings (though this only impacts 2 characters — dotted and dotless “i”/”I” — and for only 2 cultures — Azeri and Turkish)

In general, this problem is called [WayBack] Case Folding and many environments do not have good and ready to use solutions for this.

Basically when working with case-insensitive language identifiers, you should always use culture invariant text comparison operations. In most languages, people use either lowercase or uppercase converted operations which for Delphi >= come down to using :

The reason is simple:

  • without any parameter, ToLower and ToUpper will use [Archive.isSysLocale.DefaultLCID.
  • without any parameter, LowerCase and UpperCase will implicitly behave as if called with TLocaleOptions.loInvariantLocale, but lots of people forget they do.

The functions ToLowerInvariant and  ToUpperInvariant  were added in Delphi XE3, but ToLower(LocaleID) and ToUpper(LocaleID) in Delphi XE4.

Instead of doing uppercase and lowercase comparisons you could also use the [Archive.isSystem.SysUtils.CompareText function.

IBX however uses case conversion, and by now you will probably guessed it: IBX got it all wrong. One reproduction is at https://gist.github.com/jpluimers/643b382944ff991d07ec96abbf85548c and a thread with background is at [WayBack] What’s the Delphi equivalent of doing UpperCase with an InvariantCulture in Unicode Delphi versions? (XE and up) – Jeroen Wiert Pluimers – Google+

IBX isn’t alone: just search for other uppercase issues like Turkish i to see tons of other issues.

For IBX, I did the replacements in the diff below to fix it in Delphi XE8. I only replaced where identifiers were compared, not were actual database content was compared.

Unluckily, in the past IBX sources were hosted on CodeCentral at http://cc.embarcadero.com/Author/102 but no new bundles have been released since 2012.

Of all the locations I think IBX should not have used any case conversion here:

IBX.IBDatabaseINI.pasfunction LocalServerPath(sFile: string): string

This function uses LowerCase() but I think an NTFS specific comparison should have been used, but I’ve not investigated into a solution for that yet.

–jeroen

Read the rest of this entry »

Posted in Delphi, Delphi 10 Seattle, Delphi 10.1 Berlin (BigBen), Delphi XE3, Delphi XE4, Delphi XE5, Delphi XE6, Delphi XE7, Delphi XE8, Development, Software Development | Leave a Comment »

Why I like PlantUML

Posted by jpluimers on 2018/06/13

Ever since I started using computers, I’ve liked text based solutions.

It’s one of the reasons I like PlantUML, but there are more. This is from a GitLab.com request I did a while ago: [WayBackPlease enable PlantUML rendering on gitlab.com both for standalone plantuml files and inside markdown plantuml code blocks (#2041) · Issues · GitLab.com / GitLab.com Support Tracker · GitLab

one of my UML gripes from the past (I’ve been a software developer for about 30 years now) was that it wasn’t text based.

After bumping into PlantUML a long time ago in 2014 I’ve become a happy user of it for a few reasons:

  • the language is text based (with many benefits I don’t need to explain)
  • the tool is cross platform
  • the tool is still actively developed all the way back from 2009
  • after rendering, the arranging of elements is much better than I expected from an automated tool

Of course every now and then there is a glitch in complex diagrams, but I’ve found that professional tools:

  1. don’t do much better in fully-automated arranging
  2. become very cumbersome to use when you to manual arrangement

My first use initially was online, then in 2016 installed it on my Mac even submitting homebrew updates for it every now and then.

Oh: I love their 404 humour at http://www.plantuml.com/plantuml/beta

Renderings can be in all sorts of graphics and text formats, for instance SVG, PNG, ASCII and Unicode.

Example:

plantuml -tsvg PSO.network-diagram.PlantUML.txt

–jeroen

via:

related:

Read the rest of this entry »

Posted in Development, Diagram, DVCS - Distributed Version Control, Fun, git, GitHub, GitLab, PlantUML, Software Development, Source Code Management, UML | Leave a Comment »