Dave Novo

@Uwe Raabe - is there any way we can help in this regard. I just upgraded to the latest MMX and generic support is basically non-existent. I cannot even copy a generic class to the clipboard to paste to another unit. If click on the class in the the MMX window and select 'Cut' it deletes the class. Then if I paste to another unit it says "Nothing found to insert". If I click on a generic class in the MMX window, the code just jumps to the top of the unit. We love MMX here, any chance of open sourcing so others can help improve it?

Hello, I am using Delphi Seattle. I am wondering if something like this is possible. I cannot figure out how query if the object supports T at the base level. TMyClass=class public function MyFunc<T:Interface>:T; end TMyDescendent=class(TMyClass,ISomeInterface) public function ReturnMyInt:ISomeInterface; end; function TMyDescendent.ReturnMyInt:ISomeInterface begin result:=MyFunc<ISomeInterface>; end function TMyClass.MyFunc<T>:T begin // do some stuff here Supports(self,T,result);// does not compile result:=self as T;// does not compile end; of course, I can always chane MyFunc to math the Supports signature (i.e. pass in IID and out Obj) but I was wondering if there was a way to do this with generics

awesome. Thank you so much!

Did you ever have a look at the old faststrings library? It was for ansi strings only, but they had a lot of good ideas. Plus, if you happen to be using ansi strings only for your application (or at least part of it) it is very fast.

@John Kouraklis - I think EMB is caught between a rock and a hard place. By every indication I can see (# of questions on stack overflow for FMX vs VCL for example) VCL developers vastly outnumber FMX developers. But EMB is not going to grow promoting VCL. They need some niche that differentiates them from C# and all the other more popular windows platforms. So X-platform is a carrot that they wave to convince people to try Delphi. It is likely good for creating a phone app that has minimal UI requirements, but the desktop FMX components I have seen so far are underpowered compared to the VCL versions. I would love to use FMX to make our desktop app properly x-platform, but after 10 years of FMX several of the key 3rd party vendors still dont have FMX versions, so its difficult to migrate. The blog post also commented that they did not even get the interest level that they had hoped for. Which is not surprising. Not sure how many people started new FMX apps that required devEx grids in the 3 months that the devEx grid was out, and 3 months is certainly too short to migrate an existing VCL app that needed devEx grids. We were certainly aware it was there for example, but migration to FMX requires a lot of moving parts, and testing the grid was not yet on the radar.

I am using Delphi Seattle and have a project group with two projects inside. One is a console app, one is a vcl app. For my debug settings I have all the proper things set to generate debug info etc etc. If I have the project settings set to NOT use MSBuild, everything works perfectly. The problem is that Delphi does not release the memory from the build process. After the first EXE compiles, memory goes to 1.6 GB. After the second compiles, it goes to 2.9 GB. It never releases the memory back to windows. It sometimes runs out of memory during the compiles, other times not. So I thought to use the out of process build and check off "Use MSBuild to externally compile". Everything compiles file, except I can no longer debug. When I put a breakpoint on a line, it turns green when the program launches, as if there is no debugging information. Its driving me bananas. This is for a win32 windows compile. If I try this in a blank VCL application with just a form and a button and a line of code in the button click, I can break on the button, but it jumps to the CPU window and not to the source when it breaks. This is even when I put the path to the source in the Debugger->Source Path for the project. This went away when I included remote debugging symbols. So I added that to my project and still could not debug. Does anyone have any tips for getting msBuild to work. I do have "include remote debugging symbols" turned on in the both whether or not MSBuild is selected.

The following code compiles fine in Delphi Seattle var m:TMemoryStream; r:TRect; begin m:=TMemoryStream.Create; m.Write(@r,sizeof(r)); m.Free; but fails in Sydney 10.4.2 on the line m.Write(@r,sizeof(r)); with a "Variable Required" error. Looking at the Delphi Help at http://docwiki.embarcadero.com/RADStudio/Sydney/en/E2036_Variable_required_(Delphi) it seems that this should not be happening, but before I report it as a bug, does anyone have any insight?

@David Heffernan - thanks. I did not appreciate the significance of WriteBuffer. Strange that there is WriteData, with lots of useful overloads, but no error checking. And WriteBuffer with error checking and just a few overloads.

@David Heffernan - I do check for errors when writing to files, databases other "external" places I am writing the data. In that case, who knows what is going on and what could have happened to the file/database connection. However, when writing to a memory stream, would you really advocate the code below? It is unnecessarily verbose, all to handle an out of memory error, which would crush my program anyhow and not easy to recover from. What other error would I be worried about here that I could realistically handle and recover from. var m:TMemoryStream; r:TRect; p:TPoint; value:integer; cntr: Integer; curVal: Integer; bytesWritten:integer; begin m:=TMemoryStream.Create; // initialize r,p, curVal with some data bytesWritten:=m.writeData(r,sizeof(r)); if bytesWritten<>sizeof(r) then raise exception('error writing r'); bytesWritten:=m.writeData(p,sizeof(p)); if bytesWritten<>sizeof(p) then raise exception('error writing p'); bytesWritten:=m.writeData(curVal,sizeof(curVal)); if bytesWritten<>sizeof(curVal) then raise exception('error writing curVal'); .... rest of the method here. m.Free; end;

That seems to be it. Turning TYPEADDRESS ON in Seattle gives the same compiler error.

The following code works perfectly in Delphi Seattle? Just luck??? var m:TMemoryStream; r:TRect; cntr: Integer; curVal: Integer; begin m:=TMemoryStream.Create; r.Left:=100; r.Top:=200; r.right:=300; r.bottom:=400; m.write(@r,sizeof(r)); m.position:=0; for cntr := 0 to 3 do begin m.Read(curVal,sizeof(integer)); showmessage(curVal.toString); end; m.Free; end; curVal.ToString reports 100, 200, 300, 400

hmm. We fixed a similar issue by doing procedure TForm1.Button1Click(Sender: TObject); var m: TMemoryStream; r: TRect; rectPtr:Pointer; begin m := TMemoryStream.Create; rectPtr:=@r; m.Write(rectPtr, sizeof(r)); // (@r, sizeof(r)); m.Free; end; I really should triple check that is working as expected.

De Novo Software is based on Pasadena, CA. If you happen to be in the area we can accommodate an onsite employee (remote until COVID is resolved) but we will also accept a fully remote position for the right candidate. Details are at https://denovosoftware.com/about-us/careers/software-developer/. We are a team of expert Delphi developers who love Delphi and have put together a cutting edge application used by scientists for state of the art research and clinicians around the world to diagnose many types of cancers and other diseases.

@Nigel Thomas - thanks!

In the situation where you have infinite time, and infinite resources, sure, the above statement is true. Most of us are not in that situation. If you want to simply answer, what is a bottleneck, that is easy... some single (or few) part of your program that throttles the entire execution path. The more difficult question is which bottleneck is worth investigating and fixing. For example, lets say you have some truly awful code in one part of the program that is causing something that should take 5 seconds to take 5 minutes. Really bad. But because of how your end users use the program, only 1% of people encounter this bottleneck. And those people all run that part of the program overnight anyhow, as part of a larger batch run. Is this even worth "looking into"? Maybe, if the "looking into" takes 10 minutes. Maybe not if the "looking into" takes a day. That is a day you are taking away from adding features, or fixing bug that affect the other 99% of your customers. How does your answer change if the bottleneck is such that something that should take 5 seconds takes 12 seconds? IMO, software development is not hard and doesn't fail usually because of programming challenges. i.e. how to code the algorithm, how to add the function. Software Development is hard because it requires choices like the one described above, to which there is no clear cut answer than anyone can give you that applies to all cases. Most coders can figure out how to write whatever SQL query you need and design a database that works. Successful projects / developers / teams consistently come up with the right answers to the more difficult questions like: what refactorings are worth the time it takes to do them? what level of "engineering" (when are you over-engineering, when are you under-engineering) is appropriate for the task I am doing? Which bugs are worth fixing? How to fix them (quick hack or deep rearchitecturing)? All of those questions are easy when you have nothing else to do, but usually that is not the case.

As a developer improves, (hopefully) the developer can write more optimized code in about the same amount of time as they used to write less optimized code. Knowing when to use a TStringBuilder instead of concatenating strings for example, and knowing when doing so will make a difference. Recognizing the use cases and intuitively selecting the data structure most suited for it. etc. Often, it does not take much longer to write faster code than slower code, if you know what you are doing. Beyond that, I would not do much optimization until you had specific use cases that were performing badly. Then, you need to profile those use cases. Once those have been profiled, sometimes it is obvious what to tackle, sometimes sadly its death by 1000 cuts. But I do not not think premature optimization is BS. It happens all the time and is generally a waste. Until you have specific use cases it does not make much sense to make much efforts to optimize, beyond what you are naturally able to do based on your skill level. You can spend hours optimizing some data structure that was never going to be a problem in the first place.

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! 😀