David Heffernan

23 minutes ago, Leif Uneus said:

The type is still extended, but the value will be as a single(0.1)

 

It's more nuanced. Assign it to a single variable, and it's just a 4 byte assignment. At least that's how it always has been for floating point literals. Its type is only really crystallised then you assign it is how you might think about it.

FWIW, const C = Single(0.1) does not compile in XE7 which is my day to day Delphi.

And it does in 10.3 and possibly earlier versions too. Which would appear to provide a way to specify the type of floating point literal when the value is not exactly representable.

I'd prefer to use a suffix rather than a type, but the precedent was set by integer types.  So, no, I don't see any unsurmountable problems here.

5 hours ago, Mahdi Safsafi said:

@David Heffernan

I believe that you are not seeing the full picture here : The real issue is the dissociative type between literal and expression (not like what you understand "the ability to control FP constants") .

BTW you don't work around an issue ... you need to fix it (fixing the type system will let you control FP type) !!

This is a critical issue ! For now it just looks less critical but just think if at some time Delphi introduces type inquiring feature ! what will happen ?

I was working on a Pascal-like compiler and I used a weak-typed literal system for constants, meaning the const was stored using the longest available type and casted on demand. I got a very surprising result when inquiring types/expressions/variables. This was my motivation to inspect Delphi constants. So I'm very sure that this aspect is wrong and will at some point produce unpredictable behaviors.

I hope -by now- that you are seeing the full picture and everything is clear for you.

 

I don't think the issue is that I don't see the full picture and have a lack of clarity. 

9 minutes ago, Mahdi Safsafi said:

No that's not the issue !! In fact the compiler by its design is free to assume literal type AND force it (prevent you from modifying it by emitting error when casting it to another type)

As far as I am concerned the only issue raised in this thread that can't be worked around is the type of floating point literals. Integer literals can be cast. But not floating point literals. 

Having said that, my recollection is that `Single(0.1)` would not compile so I wonder if there has been a change since XE7, the version I am most familiar with. 

The inability to control the type of a floating point literal is the only real issue here. 

Everything else mentioned above can be readily worked around. But the fact that you can't control the type of a floating point literal presents problems that have no workaround. 

I want to write

const

  s = 0.1s;

  d = 0.1d;

And have two literals with different values. 

2 hours ago, Skrim said:

Thanks, I thought they were set by default.
Moral, don't take anything for granted 🙂

 

 

They should be, don't know why Emba doesn't do this 

You should enable both range checking and overflow checking. Then you'll see your exceptions. 

The actual bug could be in eithsr of these plugins, or another plugin, or the IDE itself. 

Curious, but why would here be VCL and FMX versions of Delete File? Isn't it an RTL function? 

39 minutes ago, Darian Miller said:

1. Windows 10 build 18363.  i7-7700K 4.2GHz, 4 cores, 8 logical processors, 64GB RAM.

2. pyscripter explained why a low pop timeout fails earlier in this thread and is why there's a minimum of 20ms in the stress tester now.  

 

The test originally failed less in a virtual environment (VMWare Workstation) so I switched to testing on physical machine.

 

On Win32, you can try throwing more threads and run into problems, likely more with Windows than Delphi.  I tested with 1,000 threads without any issue.

Win64 could handle 50,000 threads without failing.

 

 

If it failed in a virtual environment, then the code is presumably defective 

I have a case in my test suite that checks compilation for all supported delphi versions of all code that I ship to clients. Pretty easy to set up. 

1 hour ago, dummzeuch said:

One of the bad habits I have picked up over the years is not looking into the documentation. The only reason I can give is that the documentation was so bad for some time that the time it took usually was wasted. Since documentation has become much better (but is still far from perfect, especially some of the examples), this no longer applies though.

I think it is often the case that documentation for Delphi is added sometime after the code is released. Documentation for mature parts of the libs is often reasonable. Not so much for newly released libs. 

I think this is a really poor way to develop libs though. I routinely find design issues when I am writing documentation. If you write the documentation after you release then you'll find those issues after the consumers have started using the libs. 

I don't think RTFM is the right way to say it. But I trust you make a mental note to check the documentation another time.

I mean, the way the message was delivered was clumsy, but the thrust of the message is valid.

4 hours ago, Leif Uneus said:

StopWatch := TStopWatch.StartNew

is all you need

OK, I was sloppy. I still don't get why you wrote this sorting function rather than use built in algos. 

Writing a sorting algorithm into a UI control is a bad idea. Keep the two separate. You'd only really need to use merge sort if you needed a stable sort. And then you'd have to take care that the merge sort algo was a stable one.

Surely there is perfectly usable built in sorting code? 

3 hours ago, pyscripter said:

Thank you all for your answers.  What is wrong with removing all these entries.  Does this cause Rad Studio to malfunction?

I remove them all. I don't have any problems.

It means I can use any of the many versions I have installed easily.

For versioned packages, e.g. vcl270.bpl then multiple entries are fine. But for non versioned tools, e.g. dcc32.exe then it's a mess.

These days it just feels a bit weak to rely on the path to find libraries. I always place them in the executable directory, or in sub directories and use SxS assemblies. 

I remove all entries and then my build scripts set up the appropriate environment for the target version, and then call msbuild.

Works for me but I'm sure there are other ways. 

Invalidate doesn't send a message. It marks the control as needing repainting and then that paint message is synthesised the next time the message queue is emptied. 

35 minutes ago, Lars Fosdal said:

It could, if more people actually bothered to.
But, yeah... I hear you.

It's a shockingly bad way for a software house to prioritise. It's susceptible to an effect known as self selection. As worthwhile as a Twitter poll. 

No. That's not what Invalidate does. It marks the paint box as invalid. And then when the message queue is next empty, a paint event gets synthesised. 

The thing is, at some point you need to make the main thread wake up and do something. What's your plan for doing that? Perhaps what you want to do is note that an update is required with a flag and then check that on an update timer in the main thread. That would be a sensible approach if the frequency of updates from the threads was very high. 

Bear in mind that in the OP you suggested sending a message from the worker thread to the main thread. Have you now decided that you don't want to do that? 

26 minutes ago, Jacek Laskowski said:

Calling Queue from the thread is a bad idea here. There are several threads, each of them processes some data, and one visual control displays them. If each thread is forcing a refresh, it will be a heavy load. And if the light gets messages, even from a few threads, it will decide how to refresh itself.

Dude, it was you that wanted to have the worker thread notify the main thread! That's literally what you asked in the OP.

26 minutes ago, Jacek Laskowski said:

How to handle the message the parent got? I don't know who the parent will be?

Why would you opt to send a message to the parent? I only said that because you can't send a message to the paint box since it isn't windowed. Which is why Queue or Synchronize are cleaner.

Ultimately, you need to call Invalidate on the paint box, from the main thread. And you need to decide what is going to trigger that to happen.  I gave you some examples, and of course there are other ways. But your have to make you own mind up.

1 hour ago, Lars Fosdal said:

Vote like the feature depends on it!

Like that works!

You'd have to post the message to the parent. But why bother. Just use TThread.Queue. 

6 hours ago, Vincent Parrett said:

Or avoid Synchronize and send custom message to the control using PostMessage(control.handle,...) and call invalidate in the message handler. 

Use TThread.Queue, not least because the paint box isn't windowed. 

You never send a WM_PAINT message to a control. You invalidate in. For a plain Win32 control that means calling InvalidateRect. For a VCL control that means calling Invalidate. 

You don't want to call that from a thread. Use Synchronize to execute code on the UI thread.