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 1,680 other followers

Archive for August, 2019

Delphi built-in data types and their memory sizes

Posted by jpluimers on 2019/08/21

Though 64-bit support was released back in 2011 with Delphi XE2, sometimes I forget which data type are native size and which keep their size no matter the compiler bitness (wiktionary/wikipedia).

This post was motivated by¬†via [WayBack] Having started with Delphi before the Cardinal type was available (Or has it always? I can’t remember.) I routinely declare 32 bit unsigned variables as… – Thomas Mueller (dummzeuch) – Google+

The most simple distinction is between Win32 and Win64, but there are more non-32 bit platforms, so these do not suffice any more:

The easiest for me are the below tables that only got introduced with Delphi 10.2 Tokyo: [WayBack] Delphi Data Types for API Integration РRAD Studio.

I have bolded the ones that change size.

Read the rest of this entry »

Posted in Delphi, Development, Software Development | 3 Comments »

Delphi generic nested classes

Posted by jpluimers on 2019/08/21

Reminder to Self: do not nest T¬†generic types as you’re in for a surprise.

Source: [WayBack] Delphi generic nested classes

Via:¬†[WayBack] An interesting question over on SO relating to nested generic classes… – David Heffernan – Google+

The surprise:

what type would you expect obj.x to be? Integer or string?

The compiler hint:

[dcc32 Hint]: H2509 Identifier 'T' conflicts with type parameters of container type


Posted in Delphi, Development, Software Development | Leave a Comment »

Turbo Pascal 7 compatible compiler for 8051 microcontrollers…

Posted by jpluimers on 2019/08/21

I had seen this before, but was glad about the reminder to put it in my blog: [WayBack] OMG, there is Turbo Pascal 7 compatible compiler for 8051 microcontrollers! – PrimoŇĺ Gabrijelńćińć – Google+:

[WayBack] Full-featured free Pascal compiler for 8051 microcontrollers, Borland Turbo Pascal 7 syntax, multi-pass optimizer, generates bin, hex, OMF-51 and asm source.

Program Turbo51;
Uses FastCompiler, AdvancedOptimizations, SmartLinker, AseemblerFileGenerator;
//  Turbo51 is released as freeware. You can download it and use it for FREE.
//  However, if you like Turbo51 you can donate some small amount via PayPal.
//  Donations are a great way to show your appreciation for my software.
    While ThereIsAProblem do
      Case ProblemSolved of
        True: Break;
        else  AskForHelp;
    If InstalledVersion < '' then Update;
    If Satisfied then Donate ($20);
  until NoMoreProjects;


Posted in Development, History, Pascal, Software Development, Turbo Pascal | Leave a Comment »

Some Markdown links on phrasing more difficult markdown for correct rendering

Posted by jpluimers on 2019/08/20

After blogging on Markdown notes in 2014, Markdown support has come a long way. It also means that the documents written in Markdown has become more complex, and that more tools can render it.

Given the vague aspects of many Markdown dialects, rendering can be troublesome (see my post Babelmark 2 online Markdown checker), so below are some links on some aspects I had trouble with getting right.

Note that there are two markdown linters:

Sometimes, issues are present in one, but not in the other; see:

The command line interface to the Ruby version is easier to install than the JavaScript version as everything is in one gem: mdl, unlike the npm, where the cli is in markdown-cli and the library in markdownlint.



Read the rest of this entry »

Posted in *nix, *nix-tools, Development, Lightweight markup language, MarkDown, pandoc document converter, Power User, Ruby, Software Development | Leave a Comment »

Python line continuation: only use backslash if it gives cleaner code

Posted by jpluimers on 2019/08/20

Since Python is a [WayBack] line-oriented programming language, sometimes you want to wrap longer lines into more readable shorter ones.

Many people struggle with this, see for instance these questions (and excellent answers!):

This struggle is likely why it made it to the [WayBack] style guide. Relevant sections are below.

I had this struggle wile passing multiple parameters to a method creating a very long line, but found I did not need a line continuation as the Python language understands this construct perfectly fine:

        UrlMonitorThread(monitor, "http://%s" % targetHost),
        SmtpMonitorThread(monitor, targetHost, 25),
        SmtpMonitorThread(monitor, targetHost, 587),
        SshMonitorThread(monitor, targetHost, 22))

You could use the line continuation backslash to do this, but often that is not needed or a better way exists (for instance wrapping an expression in parentheses), so here are are the relevant style guide sections:

Code lay-out


Use 4 spaces per indentation level.

Continuation lines should align wrapped elements either vertically using Python’s implicit line joining inside parentheses, brackets and braces, or using a¬†hanging indent[7]. When using a hanging indent the following should be considered; there should be no arguments on the first line and further indentation should be used to clearly distinguish itself as a continuation line.

Maximum Line Length

Limit all lines to a maximum of 79 characters.

For flowing long blocks of text with fewer structural restrictions (docstrings or comments), the line length should be limited to 72 characters.

Limiting the required editor window width makes it possible to have several files open side-by-side, and works well when using code review tools that present the two versions in adjacent columns.

The preferred way of wrapping long lines is by using Python’s implied line continuation inside parentheses, brackets and braces. Long lines can be broken over multiple lines by wrapping expressions in parentheses. These should be used in preference to using a backslash for line continuation.

Backslashes may still be appropriate at times. For example, long, multiple with-statements cannot use implicit continuation, so backslashes are acceptable:

with open('/path/to/some/file/you/want/to/read') as file_1, \
     open('/path/to/some/file/being/written', 'w') as file_2:

Make sure to indent the continued line appropriately.

Should a line break before or after a binary operator?

For decades the recommended style was to break after binary operators. But this can hurt readability in two ways: the operators tend to get scattered across different columns on the screen, and each operator is moved away from its operand and onto the previous line. Here, the eye has to do extra work to tell which items are added and which are subtracted:

To solve this readability problem, mathematicians and their publishers follow the opposite convention. Donald Knuth explains the traditional rule in his¬†Computers and Typesetting¬†series: “Although formulas within a paragraph always break after binary operations and relations, displayed formulas always break before binary operations”¬†[3].

Following the tradition from mathematics usually results in more readable code:

# Yes: easy to match operators with operands
income = (gross_wages
          + taxable_interest
          + (dividends - qualified_dividends)
          - ira_deduction
          - student_loan_interest)

In Python code, it is permissible to break before or after a binary operator, as long as the convention is consistent locally. For new code Knuth’s style is suggested.


Posted in Development, Python, Scripting, Software Development | Leave a Comment »

%d bloggers like this: