David Heffernan

In fact, when you put 1.025 into a double precision variable, what is stored is the closest representable value to 1.025 which happens to be 1.024999999999999911182158029987476766109466552734375.

Isn't your problem simply that you are using wrong type. You should be using a decimal type.

If you want to build a VCL app then you need to fit into the framework. The main form is the first one created by a call to Application.CreateForm. Can be valle anything. Does not need to be Form1. You can create other forms before the main form if you want. The outer begin/end block in the dpr file is the effective entry point. You arent going to have immutability with VCL controls. If you want immutability, look elsewhere. Are you building a GUI app?

Logging allows you to avoid the part where you repeatedly start up and navigate to the point of interest.

I guess you already use logging to save time. One thing that I hanker after is a reversible debugger, where you can step backwards. Tricky to implement I am sure.

I just use lapack for fft, seems not much point in trying to create yet another implementation

Because the computer has ARM processors would seem like the obvious reason

Not such much on Linux

This has always been fine here. How can this be reproduced?

Could be anything. Could be that you are splitting a vcl app between an exe and a dll. Sounds like you haven't diagnosed the problem yet. That's what I would try to do first rather than trial and error ideas like you are asking us for help with.

You could do that

No. Longstanding limitation. Kinda sucks. Can't have multiple helpers which would be another way to do what you want.

The ZIP file headers are parsed and stored when you call Open. So I don't think this should be especially slow. However, it is wasteful to call FileNames repeatedly because it is a property with a getter method that makes a new dynamic array every time you access it. So I'd do it like this var zip := TZipFile.Create; try zip.Open(fZipFilename, zmRead); for var fileName in zip.FileNames do Memo1.Lines.Add(fileName); finally zip.Free; end; (not sure if the inline var inside the for declaration works, but if not you know what to do!) Although actually in this case you could simply write var zip := TZipFile.Create; try zip.Open(fZipFilename, zmRead); Memo1.Lines.AddStrings(zip.FileNames); finally zip.Free; end;

What was you actual code. The code here is not real.

Is TryStrToFloat the bottleneck? Or is it reading the text file? Did you profile yet?

Do you need to know whether or not the value is in the valid range of your target data types? Also if you need to do this fast then you probably won't be using a string for each line becasue that involves heap allocation.

In this case I don't understand what you are saying. I thought you wanted to override the default system theme. But it seems I misunderstood you.

Just to be pedantic, but more "tasks" than CPUs is not a problem. The problem is when you have more runnable threads than CPUs.

So what? Assuming your tasks for CPU bound then set the thread pool thread count to match the number of CPUs, and let the scheduler do its job.

The asker already knows this. The question is not how to find N but how to control task scheduling on thread pools.

Machines have a fixed and well defined number of processors that can readily be queried. So it's trivial to know what N is.

Create a thread pool with 8 threads and assign the tasks to that thread pool. Incidentally does anybody know why the default thread pool has more threads than CPUs?

Isn't the entire point of the system theme that there is system wide consistency?

You've probably answered the question yourself. DesignIde brings the others with it. Now your exe will link to different instances of rtl and vcl I think. Statically linked rather than runtime packages. Which might be a problem. Solution likely to involve getting rid of dependency on DesignIde.

Article says the bugs will be fixed shortly