Dave Novo

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

As usual, there is no correct answer. Just opinions/options. Option 1: Just use FreeAndNil all the time. This way, you don't have to think about it, you can code it up in the Delphi IDE auto-complete stuff (and other tools like MMX). It is doing a bit of extra work, and calling an extra method, but you would need to doctor up some very contrived examples to have the speed penalty from FreeAndNil make any kind of impact on your code performance. Option 2: Use FreeAndNil if you free objects in the middle of a method when there is code executing afterwards and you are scared you may accidentally use the freed variable. Also use FreeAndNil in explicit cases where a valid state of an object variable is NIL. If you free objects as the last few lines of a method (or in a destructor) dont use FreeAndNil and rejoice at the nanoseconds of processing speed you have saved compared to option 1 Option 3: never use FreeAndNil. If you use FastMM there is an option on it to catch the use of freed memory. That option does slow down things quite a bit, but it works. That way, even if you reuse a freed object variable, FASTMM will throw an exception. Or, if you dont use FastMM then simply don't make coding errors 🙂 Seriously though, it can take ages to find errors stemming from using freed memory if you dont have FastMM debug mode on, and all the nanoseconds in the world saved from not using FreeAndNil is not worth the hours it will take you to find the bug.

Hi John. Package management on python is something that you need to learn and understand before using Python. If you just install packages willy nilly you will essentially have a non-functional python environment after a while. There are many tools available to help you not shoot yourself in the foot. Out of the box python supports virtual environments. There are package management tools like Conda, Poetry and others. It takes a bit to wrap your mind around it, but just like in Delphi if you install packages where different packages require different versions of other packages you will get yourself into big trouble. Its just that in python you use many more packages (aka 3rd party libraries in Delphi) and the odds that some conflict are much higher simply since there are more of them.

Evidently, there are issues with cycles. I do admit that our huge 3M LOC application has tons of cycles (where we have stuff in the implementation uses clause that would cause circular references if it was put in the interface). We are working on removing these because evidently they slow down the compiler as well. Over the last 20 years we were not aware there was any downside in having cycles and took no effort to refactor things to prevent them. Now we are far more careful. Evidently, LSP (even Delphi 12.3) does not like these and simply dies on our application. However, that does not explain that even in my relatively simple apps it is still unreliable.

Unfortunately, we are not. The company has too many hoops to jump through to get anything out as open source. Plus we used a lot of our base classes and libraries to speed up the coding, so would have to disentangle that.

I agree with you. The LSP simply is unusable on our project and we were forced to write our own IDE plugin and utilize DelphiAST to write our own code insight and code completion. Even in much simply projects I am writing (<10 units, a few hundred lines of code) the code completion, ctrl+click to jump to an identifier, does not work well.

Welcome to the Delphi world. There are lots of tools available for many of the questions your asked. Have a look at the subforum on this site and search for various tools and you will see many examples. Most of the tools have been around for a long time, and are very feature complete and differ by subtleties of usage etc. Delphi Third-Party - Delphi-PRAXiS [en] -for the diagrams, I know both TMS Software and Developer Express have flowcharting tools you can leverage. There are other lesser known ones that are available. Just google "delphi flowchart component" -Similar with Help tools. We used Help and Manual and liked it, but there are many other tools equally as valid. These do not even have to be delphi specific. -Please describe what "font oddities" you are seeing in more details. -Without knowing in more detail what you want, recommending a database is just throwing darts against the wall. All have their pros and cons.

ok, perfect, I got that working. thanks!