The Wiert Corner – irregular stream of stuff

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

  • My badges

    Mastodon

  • Twitter Updates

  • Pages

  • All categories

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

    Join 1,839 other subscribers

Archive for the ‘Software Development’ Category

« Previous Entries
Next Entries »

Not sure why, but sometimes the Delphi IDE does not allow you to toggle the Console Application; it looks off, but is in fact on: IsConsole returns true

Posted by jpluimers on 2019/03/28

On my research list: Not sure why, but sometimes the Delphi options display a regular application, but the IsConsole returns true because of AppType Console in the main PropertyGroup.

  1. console applications are turned off in the linker
  2. the debugger still shows it as a console application when stepping through the initialization section of the System unit

One of the problems is that unlike the {$APPTYPE directive (which has not changed much over time), the AppType element is undocumented (hardly anything in the .dproj file is documented).

The $APPTYPE lists two values: Console and GUI, defaulting to GUI:

Empirically, the AppType element can have these values:

  • Application
  • Console
  • Package

This is the topmost part of the .dproj file does not matter, without AppType element valued Console, or with it or even having it valued Application: either way a console application is being built.

There is no $APPTYPE in the .dpr or any of the .pas files.

The IsConsole variable is always false and a console window always appears when debugging.

That variable is not always conclusive, as there are situations where code is inside a BPL or DLL started by an EXE, so this works better: [WayBack] How to determine if I’m running as a console app? (Delphi on Win32) – Stack Overflow:

function IAmAConsoleApp: Boolean;
var
  Stdout: THandle;
begin
  Stdout := GetStdHandle(Std_Output_Handle);
  Win32Check(Stdout <> Invalid_Handle_Value);
  Result := Stdout <> 0;
end;

The .dproj files:

Read the rest of this entry »

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

Windows Manifest Files and Delphi

Posted by jpluimers on 2019/03/28

An interesting read on Windows Manifest Files in Delphi [WayBack].

TL;DR:

Do not let Delphi manage your manifest. All versions are either limited, or buggy, or both.

Basically it’s the same as doing VersionInfo in Delphi: do not let the IDE do it, but do it yourself. In this case:

Write your own manifest in XML, then load it as a resource.

Via: [WayBack] Blogged : Windows Manifest Files – In this post I look at Windows Manifest Files, what they do, why we need them and how to use them in Delphi and Finalbuilder… – Vincent Parrett – Google+

–jeroen

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

*Recursive Parallel For Loops*…

Posted by jpluimers on 2019/03/28

Interesting thread: [WayBack] Recursive Parallel For LoopsI have an algorithm which isn’t a sorting algorithm but conceptually works similar to the Quicksort algorithm… – Steve Maughan – Google+

TL;DR: when splitting recursive algorithms in parallel, ensure you have a way to hard limit the number of threads.

–jeroen

Posted in Development, Multi-Threading / Concurrency, Software Development | Leave a Comment »

A while ago, Lars Fosdal was on a .NET and C# link spree. Some of his links are here

Posted by jpluimers on 2019/03/27

–jeroen

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

Value types not having parameterless constructors…

Posted by jpluimers on 2019/03/27

The list below is based on a G+ discussion in a single language, but has way broader aspects.

It’s on value types, mutability, parameterless constructors and expectations of compiled code.

I’ve bitten myself in the foot with mutable types in too many languages too often, so I started advocating this years ago at clients, and now in this blog-post.

TL;DR:

Read the rest of this entry »

Posted in .NET, C#, C++, Delphi, Development, Jon Skeet, Software Development | 2 Comments »

When I ever go and use the Spring4D activator, these are some URLs I need to re-read

Posted by jpluimers on 2019/03/27

When I ever go and use the Spring4D activator, these are some URLs I need to re-read:

–jeroen

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

Bootable CD + retro game in a tweet

Posted by jpluimers on 2019/03/26

Cool: [WayBack] Bootable CD + retro game in a tweet

[WayBack] alokmenghrajani on Twitter: “perl -E ‘say”A”x46422,”BDRDAwMQFFTCBUT1JJVE8gU1BFQ0lGSUNBVElPTg”,”A”x54,”Ew”,”A”x2634,”/0NEMDAxAQ”,”A”x2721,”BAAAAYQ”,”A”x30,”SVVVqogAAAAAAAEAF”,”A”x2676,”LMBaACgB76gfbgTAM0Qv8D4uYAI86qqgcc+AXP45GA8SHIRPFB3DTeYSEhyBSwCa8CwicMB3rSGtkDNFSYwJHvc68MA”,”VapVqlWq”x330’|base64 -D>cd.iso”

Via: [WayBack] A whole game within a single tweet! Wow. That’s some 1337 skills :) – Lars Fosdal – Google+ 

By Security engineer at Square. Previously co-author of Hack and put the ‘s’ in https at Facebook. Maker of CTFs.

 

–jeroen

 

Posted in Development, Software Development | Leave a Comment »

Image recognition with C# and Emgu libraries: a .NET wrapper around Intel OpenCV – CodeProject

Posted by jpluimers on 2019/03/26

Cool article for doing image stuff from within C#: [Archive.is] Image recognition with C# and Emgu libraries – CodeProject

–jeroen

Posted in .NET, C#, Development, 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 »

Python Data Science Handbook | Python Data Science Handbook

Posted by jpluimers on 2019/03/21

Cool stuff: [WayBack] Python Data Science Handbook | Python Data Science Handbook.

Based on that I learned a lot of things on book publishing:

Via: [WayBack] You can read the Python Data Science Handbook by @jakevdp for free on his website  – ThisIsWhyICode – Google+

–jeroen

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

« Previous Entries
Next Entries »