Dave Novo

Thanks for all the amazing work you do and contribute to the community!

I pressed the >> button on the TestInsight menu, with no tests populated in the window. It still ran all the tests, and then populated the window. It took 83 seconds. I am not sure if that is because my project file has the following code {$IFDEF TESTINSIGHT} if IsTestInsightRunning then begin TestInsight.DUnitX.RunRegisteredTests; exit; end; {$ENDIF} so when TESTINSIGHT is defined, it is running all the tests. I am not sure what I need to do in order to get the TestInsight window to populate without running the tests.

Instead of adding complex features to modelMaker, this is exactly where AI shines. You simply setup Claude.ai and activate the Model Context Protocol that it can access files on your hard drive. Then tell the AI to read your units and tell it to move the relevant methods over. It can do this kind of stuff very easily, and understands much of Delphi and how do the refactorings. When I asked it to do similar things, it even filled in the uses clauses for me (even though I forgot to ask it specifically) and did the relevant initialization and finalization of the unit that was required.

Thanks all for the prompt response!

I am trying to create a "universal" Dproj file to use with DunitX, Delphi 12.3 and TestInsight 1.2.0.8. What I want to achieve is as follows: When I open the project the first time and open the TestInsight window in the IDE, the TestInsight window automatically populates with available tests. Not sure if that is even possible, or if I have to compile/run the program once. If so, that is an issue, my tests take about 2 minutes to run completely, and I am loath to have to wait 2 minutes to run all the tests just so they can be registered with the testInsight window. The workaround I have found is to find my shortest test and hit Alt+F9. Then all the tests get registered. But are the test names from the previous run not stored in some config file or something so that the IDE window can be refreshed (even if out of date potentially) when the TestInsight window first opens? The other issue is that the IsTestInsightRunning code below always returns True. Even if I reboot the machine, start Delphi and compile my project with the TestInsight IDE window closed, it still returns true and starts running the registered tests. I can see the testInsight window in the IDE briefly flash open with my one test selected (because RunRegisteredTests is executed), it runs that single test, and then closes. Is there a way to figure out whether or not the TestInsight window is open in the IDE? below is the code in my project file program TestingProj; {$IFDEF TESTINSIGHT} {$UNDEF UseConsole} {$ENDIF} {$IFDEF UseConsole} {$APPTYPE CONSOLE} {$ENDIF} {$STRONGLINKTYPES ON} uses System.SysUtils, {$IFDEF TESTINSIGHT} {$DEFINE UseVCL} TestInsight.Client, TestInsight.DUnitX, {$ENDIF} {$IFDEF UseVCL} VCL.Forms, DUnitx.Loggers.GUI.VCL, {$ENDIF } {$IFDEF UseConsole} DUnitX.Loggers.Console, {$ENDIF } DUnitX.TestFramework, TestingUnit in 'TestingUnit.pas'; {$IFDEF TESTINSIGHT} function IsTestInsightRunning: Boolean; var client: ITestInsightClient; begin client := TTestInsightRestClient.Create; client.StartedTesting(0); Result := not client.HasError; end; {$ENDIF} begin {$IFDEF TESTINSIGHT} if IsTestInsightRunning then begin TestInsight.DUnitX.RunRegisteredTests; exit; end; {$ENDIF} try {$IFDEF UseVCL} Application.Initialize; Application.CreateForm(TGUIVCLTestRunner, GUIVCLTestRunner); Application.Run; {$ENDIF} {$IFDEF UseConsole} //Check command line options, will exit if invalid TDUnitX.CheckCommandLine; //Create the test runner var runner := TDUnitX.CreateRunner; //Tell the runner to use RTTI to find Fixtures runner.UseRTTI := True; //When true, Assertions must be made during tests; runner.FailsOnNoAsserts := False; //tell the runner how we will log things //Log to the console window if desired if TDUnitX.Options.ConsoleMode <> TDunitXConsoleMode.Off then begin var logger := TDUnitXConsoleLogger.Create(TDUnitX.Options.ConsoleMode = TDunitXConsoleMode.Quiet); runner.AddLogger(logger); end; //Generate an NUnit compatible XML File var nunitLogger := TDUnitXXMLNUnitFileLogger.Create(TDUnitX.Options.XMLOutputFile); runner.AddLogger(nunitLogger); //Run tests var results := runner.Execute; if not results.AllPassed then System.ExitCode := EXIT_ERRORS; {$IFNDEF CI} //We don't want this happening when running under CI. if TDUnitX.Options.ExitBehavior = TDUnitXExitBehavior.Pause then begin System.Write('Done.. press <Enter> key to quit.'); System.Readln; end; {$ENDIF} {$ENDIF} except on E: Exception do System.Writeln(E.ClassName, ': ', E.Message); end;

I don't think its as simple as that. Here is a real case from my production code. Both the variables 'allData' and 'recoveredMixMat' are of type IShared<MtxH.MtxWithHeader.TMtxWithHeader>, yet one can be debugged and the other cannot. In this case, both variables were created exactly the same by calling NewMtxHFromFile which loads a data file from disk and returning a IShared<MtxH.MtxWithHeader.TMtxWithHeader> yet the watch list I think the debugger is messed up in many different ways, both with inline variable declaration and dealing with anonymous functions that return objects. Other times I have gotten that the IShared variable is simple "inaccessible", which usually can be cleared up by doing "Allow side effects and function calls" but it does not resolve these.

I love using IShared with Spring4D. Particularly with inline variable declaration. However, the debugger behaves so finicky and random. See the following example For some reason, I can debug SharedBmp just fine, but not sharedForm. In this case, it does not matter if I use inline variable declaration or put it in the var section of the method. It also does not matter if I click "Al;low side effects and function calls". I cannot debug sharedForm. This is just an example. It has nothing to do with using Shared<T>.Make vs Shared.Make<T> variants. It randomly works or not either way. If I introduce a temporary variable with inline declaration, I can debug again but that means that I realize I need to debug something I need to recompile. I have tried lots of variants, like sharedForm().Width in the Watch list but it never works. Is there a trick to make IShared reliably work with the debugger? Sorry about the small screenshots. I have no idea why they look so small. They look much larger in Paint before I paste them into the editor.

The difference between a ternary operator and iif<T> as you describe is that both operators are not evaluated with the ternary operator. Only the one satisfying the condition For example isVisible:=if Assigned(Foo) then Foo.Visible else False which will work vs isVisible:=iif<Boolean>(Assigned(Foo),Foo.Visible,False) which will crash if Foo is not assigned, according to the implementation you describe.

Isn't the point of Future that you create the Future and it immediately begins processing something in a background thread? Usually, it is calculating some sort of value that you don't need for a while. Then you execute a bunch of other code. When then code is done, you request the future.Value. This will block until the thread calculation you started originally is completed (or not block at all if the calculation was already done). If you are not going to block and wait for the value at some point, why use a future? Why not just launch it in a background thread, like Dalija suggested above? For example, you have a large matrix of values, and you need to calculate the mean of all the columns. But you dont need the mean until the very end of the method. So you can start calculating the mean at the beginning of the method, in a future. The rest of the method can execute, and at the very end you request the mean of all the columns from the future and do what you need with it. Or this can be the result of a complex database query inside the future, or any number of examples. There is not much difference between a TFuture and launching a TTask at the beginning of the method and then doing TTask.WaitForAllTasks passing in the task you created as far as I can tell. Just some semantic niceties with TFuture if the background task you are running just has a single result.

What you are doing is very error prone, for the reasons you describe. If you are using low valued integers, you could inspect the value of the objects[x,y] and if the value is below some threshold, then do not free it. One way of doing this is 1. Make sure to set all objects[x,y] to zero 2. if setting it to an integer value, set it to the negative of the integer you want. Make sure to when using the value to negate it again 3. If setting to an object, store the pointer as a positive integer then, when freeing, only free where objects[x,y] is a positive value. I think that will work for 32 and 64 bit until you have set your 32 bit app to specifically use memory above 2GB block.

Just to follow up on this, does anyone have an example of how to do this? There is a demo in the P4D showing how to use a numpy array that contains integers. But each column of a Pandas dataframe can be a different datatype. Does anyone have some code that shows how to check the datatype of a numpy array and then loop through the data and put in the appropriate data types (i.e. int, single, double, string, boolean).

Can you just include the pascal code of what you are trying to size. Never mind implement it... The term "setlength for 3 TArray<Double>" is unclear. Are you trying to size arr_3D: Array of array of array of double? if so, SetLength(arr_3d, a,b,c) should work (where a,b.c are the dimensions you want) Note, SetLength will set the newly allocated memory to zero. or 3 different 1D array of double

What we have done is have a centralized imageList in a datamodule for the application. We then have separate actionList/imageList pairs on every form. In the form Create, we copy the image(s) we need for that form from the central image list to the image list on the form being shown. Its a bit of a pain, we have a list of constants on the central datamodule so we can request images in an easy to read manner. So, on any given form's Create, we do something like actExportToExcel.ImageIndex:=CentralImageDataModule.AddImage(self.ImageList,IMG_EXPORT_TO_EXCEL) Its a bit of a pain and we have some utility functions like CentralDAtaModule.AddImageIndices([act1,act2,ac3],[CONST1,CONST2,CONST3]) to make it a bit simpler. But that way we can update the images in the central data module and have them update everywhere.

You can also do this from the python side and send a script to delete all global variables # List of built-in attributes to preserve preserve = set(dir(__builtins__)) # Iterate over global variables and delete those not in the preserve list for name in list(globals()): if name not in preserve and not name.startswith("__"): del globals()[name]

Hi Paul, As you can see, multiple excellent developers (I exclude myself from the list) have chimed in, with many different opinions, all of them valid. One point that you might not be aware of, is that when you free an object, the variable is still pointing to a location of memory on the heap. Until that memory is overwritten (as far as you should be concerned memory is randomly allocated and you cannot control/predict that) the object may behave fine. i.e. you can call methods on that freed object, and it will appear to work. Or, depending on what memory is overwritten, some of the methods on the object will appear to work, others will crash with an access violation or other error right away. The problem is that the crashes are quasi-random. Sometimes accessing the freed variable may crash right away, other times not. In my experience, it crashes more reliably with a 64 bit compile than 32 bit compile. This can be terribly hard to track/reproduce/fix if it only happens at a customers' site but does not crash on your computer, since for whatever reason, the memory is not reallocated on your computer in the same manner. I would HIGHLY advocate learning how to use FastMM in debug mode and use that ALL THE TIME when developing code. You can turn it off when compiling for release. I