The Wiert Corner – irregular stream of stuff

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

  • My badges

  • Twitter Updates

    • RT @nadineswagerman: Iemand mailde me dat een 13-jarig meisje mijn novelle had uitgekozen om te lezen/bespreken op school. Het boek bevat 9… 5 hours ago
    • RT @jilles_com: Afgelopen 10 dagen hebben we door NL gereisd, elke dag een nieuw hotel en op heel veel locaties gegeten. In 60% van de geva… 5 hours ago
    • RT @FTM_nl: Sywert van Lienden plaatste bewust een serie tweets om het ministerie onder druk te zetten om de omstreden mondkapjesdeal met h… 6 hours ago
    • RT @ArmsControlWonk: China just used a rocket to put a space plane in orbit and the space plane glided back to earth. Orbital bombardment i… 6 hours ago
    • RT @shossontwits: O jee. Nu dit weer. 6 hours ago
  • My Flickr Stream

  • Pages

  • All categories

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

    Join 2,482 other followers

Archive for April 6th, 2021

LeanEssays: What If Your Team Wrote the Code for the 737 MCAS System?

Posted by jpluimers on 2021/04/06

[WayBack] LeanEssays: What If Your Team Wrote the Code for the 737 MCAS System?.

When involved in writing systems, I always ask the question “Is a large crisis possible because of this system?”. When yes, such a system needs engineering mode, resulting much more vigorously asking questions on the things that can wrong and how to prevent anything that can go wrong.

So I wholeheartedly agree with Mary Poppendieck making these statements in the above article:

  1. One thing we knew for sure – we were responsible for designing safe systems, and we were not going to delegate that responsibility to anyone else. Another thing we knew for sure was that anything that could go wrong would eventually go wrong – so every element of our systems had to be designed to fail safely; every input to our system was suspect; and no output could be guaranteed to reach its destination. And because my seasoned engineering colleagues were suspicious of automation, they added manual (and very visible) emergency stop systems that could easily and quickly override my automated controls.
  2. would you write the code as specified, or would you ask some questions – such as “What if the stall signal is wrong, and there really isn’t a stall?” Or “Under what conditions do we NOT send an adjustment signal?” Or “When and how can the system be disabled?”

Software engineers need to understand what civil engineers learn as undergraduates – safety is not someone else’s job; it is the responsibility of every engineer involved in the design and implementation of a system whose failure might cause harm. If your team is not ready to accept this responsibility, then call yourselves developers or programmers or technicians – but not engineers.

Proper engineers can do this, even in an agile environment.

–jeroen

Via [WayBack] Mary Poppendieck on Twitter: “It was not a software malfunction that caused two 737 MAX airplanes to crash – the software did exactly what it was supposed to do. But does this mean that software engineers have no responsibility for safety? My 2 cents: …”

Read the rest of this entry »

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

msbuild verbosity is not passed to the Delphi command-line compiler any more, but for found units, you can use /p:DCC_OutputDependencies and for dfm/resource files /p:DCC_OutputDependencies

Posted by jpluimers on 2021/04/06

Last week, I wrote about msbuild verbosity levels. The post was both for my own documentation, but also out of need as I wanted to have way more verbose logging for a Delphi build process involving search path configurations.

When using my Delphi build script you can both pass msbuild options and Delphi compiler options:

Run-Dependend-rsvars-From-Path.bat 5 msbuild -verbosity:detailed "/p:DCC_OutputDependencies=true" MyProject.dproj

The bold one is the msbuild parameter, the italic one the Delphi compiler parameter for unit dependencies. They are directly passed to msbuild:

...\msbuild.exe /target:build /p:DCC_BuildAllUnits=true /p:config=Debug -verbosity:detailed "/p:DCC_OutputDependencies=true" MyProject.dproj

You can multiple options too:

Run-Dependend-rsvars-From-Path.bat 5 msbuild -verbosity:detailed "/p:DCC_OutputDependencies=true" "/p:DCC_Quiet=false" MyProject.dproj

In addition to unit dependencies, you can also get an overview of .dfm and other resource file dependencies by passing /p:DCC_OutputDRCFile=true on the command-line this will generate a DRC file that not just has all the resource string constants in it, but also a comment section specifying all resource files including these file types:

Both DCC_OutputDependencies and DCC_OutputDRCFile can also be set to true in a .dproj file and are configurable under two different project option paths:

  • DCC_OutputDependencies: “Project Options” -> “Delphi Compiler” -> “Compiling” -> “Output unit dependency information”
  • DCC_OutputDRCFile: “Project Options” -> “” -> “Delphi Compiler” -> “Linking” -> “Ouput resource string .drc file”

The -verbosity:detailed however, is not passed to the various Delphi DCC compilers, as somewhere along the line, the CodeGear.Delphi.Targets got changed to Quiet="true" somewhere in-between Delphi 2007 and Delphi 2010.

Delphi 2007 had from Borland.Delphi.Targets files containing from Quiet="$(DCC_Quiet)"; the file got renamed and changes likely in Delphi 2009. See these related posts:

This means as of then on, the DCC commandline compilers will always output non-verbose logging. Even specifying "/p:DCC_AdditionalSwitches=-Q-" will not help: you will just get blank lines.

In the past, one of the things the verbose DCC logging would help you to see which files where accessed using the actual build. This was a tremendous help when figuring out search path problems that kick in every now and then.

For units, there is a little trick you can use here: it’s the /p:DCC_OutputDependencies=true" option you see above.

It will output an additional file with the .d extension that:

  • on the first two lines are an empty line followed by lining having the the .dpr filenamea space and a backslash
  • continues with units in reverse order of dependency:
    • optional lines having two tabs, a full .dcu filename (even if the file was actually a .pas file), a space and a backslash
    • a final line having two tabs, a full .dcu filename (even if the file was actually a .pas file) but no space or backslash

That file is relatively easy to scan or parse for path problems.

Project settings

I am not sure at which Delphi version the depends feature became a project setting, but it is. The odd thing: it does not always work, at least not in the Delphi 102. Tokyo installations I have used.

In a .dproj file, it is inside this element: <DCC_OutputDependencies>true</DCC_OutputDependencies> just like the msbuild name.

In the UI, you can find it here:

Related

–jeroen

Posted in Continuous Integration, Delphi, Development, msbuild, Software Development | Leave a Comment »

Delphi TestInsight: running both DUnitX and DUnit tests in a test project

Posted by jpluimers on 2021/04/06

If you want to run both DUnitX and DUnit tests in a test project using TestInsight as runner encapsulation, then you need to be aware that when there are no DUnitX tests, it will raise an exception.

So use this code to prevent that:

    try
      TestInsight.DUnitX.RunRegisteredTests;
    finally
      TestInsight.DUnit.RunRegisteredTests;
    end;

–jeroen

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

 
%d bloggers like this: