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,861 other subscribers

Archive for the ‘Event’ Category

web services – Accessing the original TWebRequest object in a Delphi SOAP Server – Stack Overflow

Posted by jpluimers on 2019/05/22

Thanks Ondrej Kelle for answering this:

uses
  System.SysUtils,
  Web.HTTPApp,
  Soap.WebBrokerSOAP;

function TTest.CallMe: string;
var
  WebDispatcher: IWebDispatcherAccess;
begin
  Result := '';
  if Supports(GetSOAPWebModule, IWebDispatcherAccess, WebDispatcher) then
    Result := Format('You are calling me from: %s', [WebDispatcher.Request.RemoteIP]);
end;

Source: [WayBack] web services – Accessing the original TWebRequest object in a Delphi SOAP Server – Stack Overflow

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | Leave a Comment »

How to Design Early Returns in C++ (Based on Procedural Programming) – Fluent C++

Posted by jpluimers on 2019/05/15

One more thing to take away from Procedural Programming: It’s Back? It Never Went Away – Kevlin Henney [ACCU 2018] – YouTube was explained in [WayBack] How to Design Early Returns in C++ (Based on Procedural Programming) – Fluent C++.

Though in C++, it applies to all programming languages that stem from a procedural background (Pascal, C#, Java, golang, to name just a few).

The article is about keeping an if/else-if/else tree, even when they can be removed becomes some of their bodies perform an early return, as

In C++, as well as in other languages, the return keyword has two responsibilities:

  • interrupting control flow,
  • yielding a value.

It basically comes down to this argument:

Essentially, the argument for Code #1 is that you need to know less to understand the structure of the code.

Indeed, if we fold away the contents of the if statements, Code #1 becomes this:

The structure of the code is very clear. There are 4 different paths based on the year, they’re independent from each other, and each path will determine the boolean result of the function (if it doesn’t throw an exception).

Now let’s see how Code #2 looks like when we fold away the if statements:

And now we know much less. Do the if statements contain a return? Maybe.

Do they depend on each other? Potentially.

Do some of them rely on the last return false of the function? Can’t tell.

With Code #2, you need to look inside of the if statement to understand the structure of the function. For that reason, Code #1 requires a reader to know less to understand the structure. It gives away information more easily than Code #2.

–jeroen

via [WayBack] Kevlin Henney – Google+: How to Design Early Returns in C++ (Based on Procedural Programming) – Fluent C++

Posted in .NET, C, C#, C++, Conference Topics, Conferences, Delphi, Development, Event, Software Development | Leave a Comment »

More Delphi debug visualizers

Posted by jpluimers on 2019/05/07

I hope that by now they are available for more Delphi versions:

Some other posts around the Debug Visualiser topic:

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | Leave a Comment »

Note that the Delphi superobject library has changed to “not maintained” in december 2018, has problems with large address aware

Posted by jpluimers on 2019/05/02

A while ago I found out the [WayBack] not maintained status · hgourvest/superobject@f1c42db · GitHub.

This means you should not use the [WayBack] superobject JSON library in Delphi any more: there won’t be any fixes.

Many people use it, especially because it used to be much more stable than the built-in JSON support of Delphi.

One breaking issue in superobject is the lack of large address space support: due to the pointer calculations in various places, it does not support pointers above the 2 gibibyte boundary as filed in the 2016 [WayBack] Issues with {$SetPEFlags IMAGE_FILE_LARGE_ADDRESS_AWARE} · Issue #22 · hgourvest/superobject · GitHub

This gives problems in at least this case:

  • enabling {$SetPEFlags IMAGE_FILE_LARGE_ADDRESS_AWARE} (in older Delphi 7 through 2006 also versions this was {$SetPEFlags $20})
  • using top-down memory allocation, for instance by:
    • a user setting HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Management value AllocationPreference to hex value 00100000
    • using FastMM4 with the (default) {$define AlwaysAllocateTopDown} setting

Example registry file and batch file to enable top-down memory (reboot afterwards):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"AllocationPreference"=dword:00100000

Command to view:

reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" | findstr "AllocationPreference"

Command to enable:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v AllocationPreference /t REG_DWORD /d 00100000 /f

Command to disable:

reg delete "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v AllocationPreference /f

Large Address Aware is a nightmare

Be very very very careful with this, and by enabling Large Address Aware to your executables, as many times they can load 3rd party libraries that often are beyond your control.

Even if there is a slight chance that your code is being used with Large Address Aware enabled, then follow guidelines line in [WayBack] windows – Unit Testing for x86 LargeAddressAware compatibility – Stack Overflow

Summary of [WayBack] memory – Drawbacks of using /LARGEADDRESSAWARE for 32 bit Windows executables? – Stack Overflow:

blindly applying the LargeAddressAware flag to your 32bit executable deploys a ticking time bomb!

by setting this flag you are testifying to the OS:

yes, my application (and all DLLs being loaded during runtime) can cope with memory addresses up to 4 GB.
so don’t restrict the VAS for the process to 2 GB but unlock the full range (of 4 GB)”.

but can you really guarantee?
do you take responsibility for all the system DLLs, microsoft redistributables and 3rd-party modules your process may use?

Edit 20240628

Earlier this year, the SuperObject Delphi library got archived on GitHub. Definitely unmaintained: [Wayback/Archive] GitHub – hgourvest/superobject: This repository has been archived by the owner on Feb 27, 2024. It is now read-only.

The XSuperObject library mentioned below in a comment has not been maintained for 4 years either ( [Wayback/Archive] GitHub – onryldz/x-superobject: Delphi Cross Platform Rapid JSON: “vkrapotkin Now ParseFromFile can read UTF8-BOM files (#136) 2d3ec01 · 2020-12-09”), so I wonder what alternatives are still available.

--jeroen

Posted in Conference Topics, Conferences, Delphi, Development, EKON, Event, Software Development | 4 Comments »

Where do you place your unit uses?

Posted by jpluimers on 2019/04/18

Over the years, I have had the question of where to put uses list entries a lot.

Last year, there was one again from a very experienced developer: [WayBack] Where do you place your unit uses? Over the years, I’ve come to preferring to place my uses in the Interface section only, even if its types, constants… – Lars Fosdal – Google+

The answer is really simple, and comes down to this:

  • use only the units you need (Law of Demeter)
  • use the units as close as possible to where you need them (this helps Minimizing Scope which is related to Information Hiding and the Proximity Principle)

Besides these Clean Code and Code Complete arguments, there is another very important argument:

The larger the scope of a unit, the more resources it takes to compile your project.

This gets worse when you have cycles in your unit dependencies.

I think it gets more than progressively worse; I have seen ~5 million line projects use close to 2 gigabytes of RAM during compilation when they had deep/long cyclic dependencies, forcing a full project build with DDevExtensions configured correctly in order to avoid out-of-memory at all.

For the above question, the poll seems to indicate the public at large gets it right:

References

A few tips from the thread:

Read the rest of this entry »

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | Leave a Comment »

Just found out about the SysUtils.FindCmdLineSwitch Function

Posted by jpluimers on 2019/04/17

I learn new things every day. So today I learned about [WayBackSysUtils.FindCmdLineSwitch Function, which was introduced in Delphi 4, but I was still messing with ParamCount/ParamStr loops.

It as not changed over time. The above docs are Delphi 2007, and these are some of the newer:

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | Leave a Comment »

ILockable/TLockable/Lockable. Similar to IManaged in Spring4D, but provides a Locked interface.

Posted by jpluimers on 2019/04/10

Had to use this to start solving threading issues in a project I inherited a while ago in a temporary way before doing a huge refactoring. Will likely need it in the future as well: ILockable/TLockable/Lockable. Similar to IManaged in Spring4D, but provides a Locked interface..

ILockable/TLockable/Lockable. Similar to IManaged(now IShared) in Spring4D, but provides a Locked interface.

Note this is very inefficient, but can be practical as a shotgun approach to start solving the mess when you inherit a project that has the “I know, I’ll use threads!” approach in it.

Replace the resource typed TNeedsLock that needs protection with a ILockable<TNeedsLock>, then route all references via a call to the Locked()() call to it.

If you need a simpler approach, then use [WayBack] Interfaced monitor lock — Bitbucket by Stefan Glienke.

–jeroen

Read the rest of this entry »

Posted in Conference Topics, Conferences, Delphi, Development, Event, Multi-Threading / Concurrency, Software Development | Leave a Comment »

Some Delphi unit testing notes

Posted by jpluimers on 2019/03/21

A few notes I wrote down when coaching a team to write better unit tests and test tooling form themselves.

  • unit tests test a unit of code
  • integrating tests test multiple units of code, which can go as far as having external dependencies
  • mocks simulate depencencies
  • unit tests are being executed by a unit test runner
  • you can group tests into test suites, which can contain other suites, and determine order of tests (which can be important for integration tests).
  • unit tests and suites register them to be eligible for running (a test without an encompassing suite presents itself as a suit with one test)
  • the runner optionally has a mechanism to filter the eligible suites and tests down to the ones actually being run

References:

In the particular case for this team, testing was mostly done using DUnit for Delphi.

Here, these are worth mentioning:

  • The configuration is not limited to the GuiTestRunner: any DUnit based test runner can use it (though the default console TextTestRunner skips it, but https://github.com/graemeg/fptest/blob/master/src/TextTestRunner.pas and https://github.com/VSoftTechnologies/DUnit-XML/blob/master/Example/DUnitXMLTest.dpr shows how it can be used).
    • It comes down to either Suite.LoadConfiguration(IniFileName, UseRegistry, True) or RegisteredTests.LoadConfiguration(IniFileName, UseRegistry, True) where
      • IniFileName contains the INI filename, for instance from ExtractFilePath(ParamStr(0)) + 'dunit.ini' or from a ParamStr parameter on the command-line.
      • UseRegistry usually is False
  • If you want to disable all exceptions for easier debugging, but still want to catch failures, then you can enable Break on Failures (see screenshot below) so breaking tests will throw an EBreakingTestFailure.
  • Registration
    • Per test or per suite
    • You do not need a ITestSuite implementing class in order to register a suite (just pass a SuitePath when registering multiple tests)
    • Basically the only reasons for having a ITestSuite implementing class (like descending from TTestSuite) are
      • to have a specific SetUp or TearDown for that suite level
      • to allow \ backslash or / forward slash in test suite names (which is unwise because a lot of tooling sees those as suite hierarchy separators)
    • function TestSuite(AName: string; const Tests: array of ITest): ITestSuite;
    • procedure RegisterTest(SuitePath: string; test: ITest); overload;
    • procedure RegisterTest(test: ITest); overload;
    • procedure RegisterTests(SuitePath: string; const Tests: array of ITest); overload;
    • procedure RegisterTests(const Tests: array of ITest); overload;
    • function RegisteredTests: ITestSuite;
  • Configuration is exclusion based
    • procedure TTestSuite.LoadConfiguration(const iniFile: TCustomIniFile; const section: string);
    • procedure TTestSuite.SaveConfiguration(const iniFile: TCustomIniFile; const section: string);
    • The configuration file default name is DUnit.ini
    • The DUnit.ini file will be saved after the GUI tests are run (overwriting any changes) when the Auto Save Configuration is enabled (which is the default)
    • All tests are configured in
      • sections
        • named (of course inside [] brackets) as Tests.TestPath, where TestPath either
          • is the name of the test class
          • is a . period separated path of suites ending in an test class
        • values having keys named either
          • the test method with a value 0 to disable the test
          • a test method followed by .RunCount with an integer value indicating how often that test needs to be executed
        • note that with either TestName=1 or TestName.RunCount=1 will disappear from the ini file because those are default values
      • There are no values to indicate tests need to be run (so by default registered tests eligible to be run are being run)
    • An example file (without .RunCount ) is at [WayBack] delphidicontainer/dunit.ini at master · danieleteti/delphidicontainer · GitHub
    • You can add comments to INI files using a semi colon at the start of the line; see [WayBack] Do standard windows .ini files allow comments? – Stack Overflow

Registration and exclusion are two separate concerns.

To configure non-GUI tests, first run the GUI tester, configure it, then copy the resulting DUnit.ini file to the environment where the non-GUI tests are being run.

Be sure to check out test decorators, and maybe amend them with dependency injection. Example for apply database setup/teardown to a full suite of tests: [WayBack] How to organize testing of DB in dUnit — IT daily blog, news, magazine, technologies

Some resurrected documentation links because not all links from [WayBack] DUnit – Xtreme testing for Delphi and [WayBack] DUNIT: An Xtreme testing framework for Delphi programs succeed.

–jeroen

Posted in Agile, Conference Topics, Conferences, Development, Event, Software Development, Unit Testing | Leave a Comment »

delphi – Why was TDataSource created originally? – Stack Overflow

Posted by jpluimers on 2019/03/14

From a while ago [WayBackdelphi – Why was TDataSource created originally? – Stack Overflow

5down voteaccepted

It is all about decoupling and indirection.

And with TDataSource there are two kinds of them:

  • Decoupling the master detail relations (TDataSource is in the same module as the TDataSets that are being bound; the detail TDataSet references the master TDataSet by pointing its’ MasterSource property to the TDataSource that points to the master TDataSet)
  • Decoupling the UI from the business layer (TDataSets are in a DataModule; TDataSource is on the Form/Frame which contains your UI controls, UI controls reference their DataSourceproperty).

Since many components can point to the same DataSource, you can quickly switch which underlying TDataSet they use by just flipping one TDataSource.DataSet property.

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | Leave a Comment »

Smart Pointers code that compiles in FPC and Delphi

Posted by jpluimers on 2019/03/06

Delphi and FPC have different language boundaries, so it is always good to read a thread discussing how to get near-the-edge cases work in both.

This case is about Smart Pointers (here called auto pointers, maybe because auto_ptr is what they used to be called in C++): [WayBack] Hi all, I am trying to make a certain piece of code cross compile between Delphi and FPC. On FPC, it compiles fine but on Delphi I get a [dcc32 Error] P… – Ugochukwu Mmaduekwe – Google+

In the end if comes down to that Delphi does not allow forward-declaration of records (it does for interfaces and classes), but that you do not need a __PAutoPtr_T = ^__TAutoPtr_T, because you can use ^__TAutoPtr_T in parameters.

In Spring4D, they are called Shared/IShared/TShared, see my comment:

Note that since these are reference counted, you might want to call them shared_ptr. If you enforce the single-instance behaviour, observe that in C++ they are now called uniqe_ptr.

In Spring4D this rename has already taken place a while ago: https://bitbucket.org/sglienke/spring4d/commits/e252b81fd3788cf5b82588721f68d00c892deb87

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | 2 Comments »