dummzeuch

Given code like this: var arr: array of TSomeLargeRecord; begin SetLength(arr, 5000); // fill the array SetLength(arr, 100); // work with the smaller array end; Does the last call to SetLength actually reduce the memory required for the array? I'm suspecting that it only reduces the internally stored capacity but the memory will remain allocated until the array is finalized, that is it goes out of scope, is set to NIL or SetLength(arr,0) is called.

Then I'm out of ideas. Last resort is probably reinstalling Delphi and keeping your fingers crossed that it actually solves the problem. Hm, maybe: If you have got another working Delphi installation, you could try to export the registry settings from there and import them into the broken installation (can't break much more, can it?) Alternatively you could export both and compare them using a text comparison tool, maybe that sheds some light on it.

Can you still open the IDE by starting bdslauncher.exe? Does double clicking a .dpr or .dproj file still work? What happens if you start bdslauncher.exe from a cmd prompt and pass a .pas file as parameter?

Have you tried to set the default application for .pas files again? In recent versions of Delphi that's an option in Tools -> Options, not sure about Delphi 2007. On the other hand, personally I don't want to open .pas files with the IDE but prefer Notepad++ for that. And I don't want to open .dpr, .dpk and .dproj files with bdslauncher either because it always opens them with the latest Delphi version (or the one that has been registered as the default handler last) rather than the one the project actually needs. Shameless plug: dzBdsLauncher

The following is about a 32 bit Windows console application. I'm trying to improve performance for analyzing a huge Mono8 bitmap, stored in memory as a an array of bytes (no TBitmap involved). For each pixel the algorithm calculates the brightness for the pixel itself as well as a few surrounding pixels and writes the result to an array of byte. Doing this single threaded takes about 1300 ms. Since this can be done by multiple threads completely independently without the risk of race conditions I have split the work into n work packages, each processing some lines of the bitmap and each processed by a separate thread. The threads have been created in advance in a thread pool. Since there is no risk of race conditions I don't use any synchronization or locking mechanism during the processing. Synchronization is only necessary for assigning a work package to a thread and for signalling that a work package has been processed. This is the relevant code of the thread's execute method and the SetNext method called by the main thread to assign a work package to it: procedure TWorkerThread.Execute; begin inherited Execute; while not Terminated do begin FNewPackageEvent.WaitFor(500); FNewPackageEvent.ResetEvent; if Terminated then Exit; //==> FCritSect.Enter; try if Assigned(FData) and Assigned(FWorkCall) then FWorkCall(FData); finally FCritSect.Leave; end; end; end; procedure TWorkerThread.SetNext(_WorkCall: TWorkPackageCall; _Data: Pointer); begin FCritSect.Enter; try if Assigned(FData) or Assigned(@FWorkCall) then raise ESigException.Create('Programmer error: Package is already assigned.'); FData := _Data; FWorkCall := _WorkCall; FNewPackageEvent.SetEvent; finally FCritSect.Leave; end; end; FNewPackageEvent is a TEvent and FCritSect is a critical section, each unique to the TWorkerThread instance. A work package consists of a data pointer and a procedure pointer (not method pointer) to call. When a work package has finished processing a counter variable gets decremented like this: InterlockedDecrement(FCounter^); The main thread also processes one work package (it's also counted as one of the threads below) and then waits for the others to finish: while WorkPackageCounter > 0 do Sleep(WorkPackageCounter); (FCounter above is a pointer to WorkPackageCounter). Since every thread only processes one work package the counter starts as the number of threads. This works fine but I get some rather odd timing: Average time on 1 calls using 1 threads 1278 [ms] Average time on 1 calls using 2 threads 877 [ms] <------ Average time on 1 calls using 3 threads 1627 [ms] <------ Average time on 1 calls using 4 threads 1580 [ms] Average time on 1 calls using 5 threads 1511 [ms] Average time on 1 calls using 6 threads 1167 [ms] Average time on 1 calls using 7 threads 1438 [ms] Average time on 1 calls using 8 threads 1036 [ms] Average time on 1 calls using 9 threads 957 [ms] Average time on 1 calls using 10 threads 847 [ms] Average time on 1 calls using 11 threads 958 [ms] Average time on 1 calls using 12 threads 843 [ms] Average time on 1 calls using 13 threads 821 [ms] Average time on 1 calls using 14 threads 715 [ms] Average time on 1 calls using 15 threads 799 [ms] Average time on 1 calls using 16 threads 647 [ms] Average time on 1 calls using 17 threads 693 [ms] Average time on 1 calls using 18 threads 656 [ms] Average time on 1 calls using 19 threads 525 [ms] Average time on 1 calls using 20 threads 613 [ms] As you can see, distributing the work to 2 threads nearly halves the processing time, but adds some overhead which is what I would have expected. But distributing it to 3 threads all of a sudden takes more time than the single threaded approach. When adding more threads the processing time goes down again until it reaches some kind of minimum with 15 threads. This timing is from only a single call, but I also tried it with 100 calls and the average was about the same. The CPU is an Intel Xeon with 4 cores + Hyperthreading which gives me a logical 8 processor cores. Can anybody give me a hint what to look for to explain the oddity of 3 threads taking longer than 2 threads?

As Uwe said: Since this works for most others (it definitely works for me), the question is rather what is broken in your System? As a first step, start with a new project and test whether it works there. If it does, there is probably something wrong with the dproj file of the non-working project.

I am working on a cheap Fujutsu Esprimo mini PC. (I am sure that at least as many people are interested in this as in Linus Torvalds having bought an expensive Apple thingy. 😕

No, but I did today.

Several years ago I wrote a Delphi IDE plugin to extend the functionality of the “Evaluate and Modify” dialog as well as the Watches window called dzDebugVisualizer and even released an update for it. Back then I wasn’t sure whether I wanted to open source it or possibly commercialize it. I am now sure that the latter isn’t worth the effort, so I have made it open source under the Mozilla Public Licence 2. Read on in the blog post.

I just released dzBdsLauncher 1.0.9. If started with a .bdsproj file, it will now not just assume that a .dpr file must exist but will check for it and if it does not exist, will try for a .dpk file. blog post here

Please file (separate) bug reports for these on SourceForge.

I'm sure somebody did test with multiple monitors with different scaling (but still with 100 % scaling on the main monitor), because I filed several bug reports regarding this configuration and got feedback. They even fixed some of the bugs, which made Delphi 11.1 nearly but not quite usable for me. That's a shame because I would really like to have some crisp text display in the editor.

Interestingly there seems to be no DeactivateFontsInfo method or procedure anywhere in the SynEdit code. That assertion was added in 1999(!). "Great", if I simply comment out that assertion this will result in many more error messages. Also, GetIt has several Exceptions within the dotNET framework (which are probably handled there). Not really a good environment to debug that problem.

Hm, does that mean that the error can be reproduced by running the "Platform selection" within the IDE? I have been looking for a way to reliably reproduce that problem. Edit: No. works fine.

You have every right to disagree. But so have I and Angus.

I do understand the basics of Git, I just don't like it and I don't like Github either. And as I am nearing retirement age, maybe I won't bother. Other things (from the application domain) are more important for my current job and if I lose that job, I'll probably retire early. Hm, maybe that could become a problem because I don't plan to stop developing software even when I retire, but probably no longer with Delphi (I don't want to pay that high price and the Community Edition is not a viable option either. Unfortunately other projects also follow that path.

The plug-in, that @Ondrej Kelle mentioned looks promising. You'd need to adjust the path which it checks for, but it shouldn't be too difficult.

He is not just talking about RTL or VCL files but about files in the search path, which as I read it includes the project search path e.g. possibly ..\libs\some\library\source Putting these into read-only folders is not feasible.

You mean that the registry settings under HKCU are not deleted because there are GExperts settings stored under that path, and because the installer detects that this path exists, it does not create the default settings for the IDE? I guess that's possible, but unlikely to cause that error message.

That's odd, because that assertion is in a destructor that is usually only called when exiting the IDE, not when starting it. The problem on exiting the IDE has already been reported several times. Please file a bug report on Sourceforge for this new problem.

No, it can't.

I can't speak for other people, only for me. And Github is the barrier for me, in particular because I don't use git, and that's because I don't see any advantage for me using it (people have tried to convince me and failed, so don't waste your time trying it again). So I'd have to start using git just to contribute to something on Github? Unlikely to happen.

That's exactly why I stopped contributing. Before the project moved to Github I had write access to the svn repository and could simply commit my changes, so for me the process has become much more complicated. Anders Melander has summed up the process on Github nicely.

What exactly do you mean by "include the sources"? If it is about not compiling the sources all the time, you could simply link precompiled dcu files. If it's about not having the compiled code in your executable, the best way is linking with packages, which has some drawbacks though. A DLL is the worst option as you would lose the ability to easily add those controls to your forms.

I'm not an active JEDI member either. I stopped contributing - as little as I did - when they switched do Github. Not sure how many active people are left in that project.