Dave Novo

The other issue I have with .Tag is that once things get complex, it is hard to know who is (ab)using the Tag property for what. You have a brilliant idea to use the .Tag of some object to associate it with another object only to find out 3 weeks and 20 hard to reproduce crashes later that someone else is also using the .Tag under certain rare circumstances for other associations. Having explicit lists to hold different types of associations eliminates those problems. If you get in the habit of using .Tag all the time, you cannot even do a search for .Tag to see who is using the .Tag of your object because the search hits so many times. We used to use .Tag quite a bit but moved away from it primarily for that reason. If its a class that we control, we will make a property just for the association, that is appropriately named. If it is a class from a 3rd party library we make a list like @A.M. Hoornweg suggested. Of course, that is just our preference based on our personal experience. Your mileage may vary.

Hello, We are using Delphi Seattle. We have a ~ 2M LOC program with hundreds of units. The 64 bit compiler is running out of memory when compiling. Even when we set to "use MSBuild" to compile in a separate process. The separate process dies with an out of memory around 2GB of RAM usage. The VM I am using has 8 GB of RAM and plenty of spare RAM when the process dies. Aside from breaking the application into different packages/projects, does anyone have any bright ideas. We are in the process of upgrading to Delphi 10.4.1. Is the 64 bit compiler still a 32 bit app?

@Uwe Raabe - thanks for the tip. Everything works great after using the config settings you suggested.

The arm M1 has an emulator https://www.computerworld.com/article/3597949/everything-you-need-to-know-about-rosetta-2-on-apple-silicon-macs.html

@Uwe Raabe - thank you for the tool. After I made it compile for Delphi I ran it, and all it seemed to do was rearrange my uses clause. An example If the unit did have the fully qualified name, it moved them to the top of the uses clause, but otherwise left things alone. i.e. Am I missing something to make it prefix the fully qualified namespaces?

@Lajos Juhász - we definately are missing the unit scope names. I did not think that would make such a big difference. Certainly easy (but tedious) to fix.

@Fr0sT.Brutal - do you have an example of how you can feed python with the pointer to the delphi array and then use this data in Python?

Hi David, Thanks for the responses. The issue is that we already have a few 100 Mb TArray<Double> already allocated on the Delphi side. We want the user to be able to access that data on the python side without making a copy. ideally, somehow tell the python structure to use our pointer (that we allocated in Delphi) as the source of the data for the numpy array (or matrix). Of course, we would have to tell the user not to modify, or reallocate the contents of that memory, it should be considered read only for them. Is that even possible? or is our only choice to create numpy ndarray array object and copy our already allocated memory into the buffer exposed by the ndarray object?

Delphi is perfect. They have run out of things to do! 😀

Developer Express styles are a whole different beast. They wrote them before Delphi had their own styling engine. AFAIK Dev Ex has no intention of supporting VCL styles. That info was from a few years ago, and things may have changed.

I agree that having two methods to access the list data is helpful. Or maybe just because I got used to it from Delphi. Even Delphi has TList.List forever, so in your example if the developer cared about speed they should be doing for i := 0 to list.Count - 1 do DoSomething(list.list[i]); Mind you, I have rarely found that this makes a difference I could actually time, but sometimes it has.

Well, if you come to Pasadena, you can visit and see it running beautifully 😀 We have a bank of 5 servers. Each one is 24 cores and 200GB of ram. They each run about 75 headless windows machines each in a citrix environment. We have 4000 visual tests that are run multiple times per day and it takes about 1.5 hours to complete a full run on that bank. The key is that we wrote our own GUI automation over the years. All we do is send keystrokes and mouseclicks to the UI. However, there are several caveats that we have developed over the years to make it work. 1. the test case NEVER contains screen coordinates. We have methods like ClickOnMenu(aMenu:TMenu,'File|Open'). That method queries the TMenu and finds coordinates of the 'file' menu item, clicks on it and finds coordinates of the open menu item, then clicks on it. Similar is ClickOnControl(form:TForm;control:TControl). The testing system finds the open form, finds the control. finds the coordindates and then sends a mouse click in the middle of the control. There are other variants if you dont exactly want to click in the middle. So in the test is says ClickOnControl(form1, form1.button1). That way, if the developer changes the form, i.e. moves button1 around, then the test is fine. If they delete button1, the test stops compiling. That being said, we wrote tons of these types of methods that are specific for the controls we use, to accommodate their oddities, like virtual string tree etc. It did not happen overnight. 2. We have a small delay after every input except certain cases. This small delay is generally enough. We also have hooked into the idle processing of the program so after sending a mouseclick / keyboard press it waits for the onIdle so the program is not processing more messages. There are a few more tricks as well. However, the upshot is that we rarely have a problem with timing any longer. For really variable processes, we have our GUI automation thread wait on a TEvent in the program and the program triggers the TEvent when the process is done so that the test knows to continue. But that is rare. Not so similar from an end user, that just sits there waiting for the screen to refresh. So, the upshot is that it was a lot of work, and likely only worth it if you are going to maintain the same program for a long time. But it can be done and today, new developers in our company have no idea the hard work that went into it and they just write scripts in a fairly high level way and the infrastructure does the rest. The test cases find the problem they are designed to test, about 50% of the time. The rest of the failures are because of bugs that are involved in things the test was doing to get to the point where it was trying to test. The other upshot is that we very, very rarely have regressions. The vast, vast majority of bugs that make it to production are in new features that have not (in hindsight) been sufficiently testing.

@Dany Marmur - the crux of the debate is that GUI testing is hard to maintain. If you do it badly, every time you make a slight change to your GUI, tons of test cases start failing for no reason. Also, GUI testing has all sorts of issues to do with knowing when the action is completed. i.e. if you click on a button, then check for a result, how long do you wait to check for the result. Often test code doing the GUI automation is in another thread, and its hard for that thread to know when the application is done what its supposed to do and then test. If you check some state too early, then the test will fail because the app is done. But then you try on your own computer, and the test passes perfectly, because the app was slightly faster on your computer compared to the testing farm. If you do GUI testing well, all these are less of an issue. Some people like the very localized testing of very specific issues that you can get from a very specific test case. With a GUI test, things can fail for all sorts of reasons, and its hard to track down. But that is also the benefit, you get failures in things you did not think of.

You will probably have better luck posting on the Intraweb forums at https://www.atozed.com/forums/

Does anyone have experience designing developer express VCL skins? We need someone to design skins that mimic the modern MAC OS UI. The one that comes with DevEx is ancient. Please feel free to pass this on and if someone has experience contact us at jobs@denovosoftware.com. Thanks.

Is it possible you are running FastMM5 with memory leak tracking on, in debug mode? That will be much slower than the one that ships with Delphi, as it is tracking all memory allocations and de-allocations for memory leak reporting purposes, bad memory overwrites etc.

A few years back, there was a post about potential cache line conflicts with TCriticalSection https://www.delphitools.info/2011/11/30/fixing-tcriticalsection/ The comments indicate it was fixed for TMonitor, but I wonder if anyone knows if it was fixed for TCriticalSection. Looking at the TCriticalSection code in Delphi Seattle, it is very complex, I guess due to cross platform concerns with records, record helpers and then windows API calls all coming into play. I could not find any code there that seems to move things onto a difference cache line, but I definitely could be missing something. Does anyone have any insight into this?

I have a section of code where I need to modify the top record on a stack. This code is supposed to be highly performant, so I would like to optimize it as much as possible. I would like to get the top record of the stack without popping and pushing it. The record is somewhat complex, so copying the data back and forth to a temporary record is silly. A sample program is below type TMyRec=record s:string; end; PMyRec=^TMyrec; var stk:TStack<TMyRec>; rec:TMyRec; prec:pMyRec; begin stk:=TStack<TMyRec>.Create; rec.s:='Hello'; stk.push(rec); prec:=@stk.Peek; // get error “variable required” prec.s:=’Goodbye’; stk.Free; end; Seems like @stk.Peek is returning the address to the Peek method, not the pointer of the element being returned by the peek method. I have tried casting in various ways but it never compiles properly. Any ideas?

In Delphi Seattle, there is no List array property. The internal array is called FItems and it is Private.

I wanted to modify the top record of the stack, without removing the record from the stack. Seems like with the way records work (copies all the time) that may not be possible with the current TStack implementation, given the intermediate records that are along the way. With our own structures, in situations that require it, we do take the effort to ensure there are no intermediate records and we get direct access to the address of the record we want to modify. I had not considered that the result of Peek would actually be a copy of the record at the top of the stack.

@Mahdi Safsafi - thank you. Very clever!

@David Heffernan Which refactoring tool do you use that reliably will change some scenario where you have lots of places across lots of units where you had something like procedure SomeProc var myList:TList<TFoo> begin myList:=TList<TFoo>.Create then you want to change all places from TList<TFoo> to TObjectList<TFoo>. So the refactor would presumably change the variable declarations and the .Create calls across all the units. It really does not work reliably for us and we have lots of search..replace with invetiable 10 minutes of compiling churn to get it all right. We tend to do TFooList=TList<TFoo> and just use TFooList everywhere for this reason. If the refactoring tools worked well, it would make that less necessary.

I am not sure what @salvadodrf wants the automation for, but for me it is for testing. The debate over the utility of GUI unit testing has been beaten to death all over the internet. The advantages/disadvantages over mocking your entire system can be found all over. Without getting into a religious debate over whether or not GUI testing is good, I am just wondering if there already exists FMX tools to allow you to drive the GUI for an FMX app like the SendInput app does for Windows. Of course, SendInput alone cannot do everything, you have to combine with VCL methods to find coordinates of controls etc, but SendInput is really the key and I have not found an analog under FMX.

related to this, one key to the testing harness that we wrote for VCL is the SendInput windows API Does anyone know if there is an analog for FMX that works across platforms? We really only care about OSX for mac. But knowing android and iOS would be helpful for others.

I would suggest having a look at https://www.amazon.com/Tomes-Delphi-Algorithms-Data-Structures-ebook/dp/B007FKB0EI It has all those basic data structures for pre generic delphi. IIRC the code is all open source. If you can find an old version with the CD you might not even have to type anything in. I will see if I have a copy of the code in the office and will attach it here if I find it.