Dalija Prasnikar

It means that it can be hard to tell whether record is initialized or not. For instance you could have TGuid.Clear method that would initialize record, but there is not way to tell what that method does comparing to TGuid.IsEmpty or any other that would expect initialized record. It is not as much that warnings cannot be emitted, but that there would be a lot of bogus warnings in such case, which defeats the purpose of a warning.

From https://quality.embarcadero.com/browse/RSP-24383 Warning/Error on record fields used without initialization

TGUID is a regular record type, so it is not initialized. Only managed types are initialized, including custom managed records.

If you have a loop you will have a capture problem, except in most trivial cases. It is not that hard to spot. The main problem is that plenty of people are completely unaware of the issue as they haven't used anonymous procedures much.

Negotiations with Stack Exchange have been completed and strike has effectively ended. You can read more at https://meta.stackexchange.com/questions/391847/moderation-strike-results-of-negotiations There is also expected update to the strike letter. Even though there was a conclusion to the strike, there are different levels of satisfaction with what has been achieved and everyone is free to continue the participation or not as they wish. This is just the end of organized process . Also some things are still being worked on (establishing AI detection heuristics for moderation in particular) and there are newly announced features coming to Stack Overflow like Overflow AI https://stackoverflow.blog/2023/07/27/announcing-overflowai/ so there is still plenty of room for things to go awry. I wish to thank everyone who participated in the strike. Every signature meant a lot.

TThread.Synchronize is blocking call and it will block until the code runs in the context of main thread. TThread.Queue adds that code in a queue and returns immediately and the code will run some time in the future. Besides those differences both procedures do the same thing, run the code in the context of main thread and are thread safe. Depending on which ones of those methods you call and in which order the output you will get can differ in order but will be deterministic in a way that you can know how that order will look like by reading the code. However, that exact order is only valid for single thread. When you have multiple threads running in the background (and with TParallel.For you will commonly have more than one) the order in which those multiple threads execute synchronized code can be interleaved and output from one thread can appear in between the output from another thread.

You should remove Application.ProcessMessages from that code as it serves no purpose. TParallel.For is blocking call and that means it will block the thread from which it is called. When you call it from the context of the main thread it will block the main thread. TThread.Synchronize and TThread.Queue procedure can only work in coordination with main thread which periodically calls (this is a bit simplified explanation) CheckSynchronize procedure that will run any pending code that requires synchronization. If the main thread is blocked - not executing any code as it is waiting for TParallel.for to finish it cannot run CheckSynchronize and it will deadlock if you use TThread.Synchronize in any code that is called inside TParallel.For because Synchronize itself is also blocking call. TThread.Queue is not blocking and code will not deadlock, but it is still not a solution because all code inside will run after TParellel.For completes. Additionally, TParallel.For will cause your application to be unresponsive for the whole time it is running, and because of that it should never be called from the main thread. If you need to parallelize some task, run additional thread that will call TParralel.For and you will be able to use either Synchronize or Queue again, and your UI will not be blocked while you are running your parallel task.

Because there are differences between different operating systems and how their internals work. In other words, some things and some workflows that are possible on one operating system is impossible on another. Like I said before ExecuteWork is internal method and MUST NOT be used. It is part of the interface so internal code can call that method when appropriate, but this method is not part of public API. Forget that it exists. Just because some method is available and can be called does not mean it is meant to be used by developers, regardless of how it is available - through interface or directly through object instance. Another example of methods that should not be called directly is TThread.Execute, or TObject.FreeInstance... there are plenty of such examples around.

Yes, it is impossible. Also this approach while works on Windows is also not the best one. The only way to wait is using fTask.Wait, but then the main thread will block and OS will kill your application. If you need to run some code after task completes the only way to do that is from within task procedure. Also if you start a task and then call wait you are defeating the purpose of having background thread in the first place. begin _Taskcomplete := false; fTask := TTask.Create( procedure begin // Here you do your task code while not _Taskcomplete do Lbl_Task.Text := ElapsedSec.ToString; TThread.Synchronize(nil, procedure begin // Here you can call code that needs to run after task is finished Lbl_Task.Text := 'task complete ..'; showMessage('we wait until Task Complete to show you this message !!'); end); end); fTask.Start; end;

Additional update: The company is starting a new site covering AI prompt design https://meta.stackexchange.com/questions/390463/starting-the-prompt-design-site-a-new-home-in-our-stack-exchange-neighborhood and Stack Overflow CEO will have a keynote at WeAreDevelopers World Congress, along with workshops presenting "bright" future of Stack Exchange Network and GenAI https://www.linkedin.com/posts/stack-overflow_we-are-one-month-away-from-wearedevelopers-activity-7079488260372058113-eOPJ/ Currently negotiation is progressing rather slowly when it comes to AI moderation policy and reading between the lines it is quite possible that it will be dragged on until the conference. What will happen after that is hard to predict.

There is no safe way to block main thread. You should never, ever block main thread, especially not on mobile devices that have slightly different workflow than Windows. And yes, don't use Sleep either. The only proper solution for your problem is not to wait, reorganize code, so you don't have to wait. Disable the UI to prevent user from starting something else while your task is running and enable the UI and run other code from within task procedure (synchronized) when the task is done. This is not a safe way. Your code is bad even on Windows, even though it seems like it works. This is the wrong way to deal with threads anywhere. Again, it is not about Delphi, it is that this is the wrong way to use threads.

This is why you are failing. The main thread should not wait for background thread to finish. If you need to run something after your task is completed you need to change your code logic and initiate that code from within TTask procedure. If you wait you will block the main thread and this is not something you should be doing, unless it is some very brief period for some cleanup (even then you need to be careful) This is how you should use TTask to run task in background and then run some code after task finishes: begin fTask := TTask.Create( procedure begin // Here you do your task code ... TThread.Synchronize(nil, procedure begin // Here you can call code that needs to run after task is finished ... end); end); fTask.Start; end; If you change your code workflow, you will not need the Sleep or anything else. There is no magic there. Just because at some point it may look like it is doing what you want it to do, does not mean it is right way to do it.

Do not call Application.ProcessMessages, it is a wrong solution to whatever problem you have.

It doesn't help much. The code does not make sense, so it is very hard to understand what you want to accomplish and even more importantly why. Delphi does support background threads on mobile devices, but again your code is very much wrong. Again, don't ever call ExecuteWork on task, use Start. It would help if you could show your original code as in what you need to do, without your broken solution which just makes it harder to understand what you need.

I don't quite understand what you mean that it didn't wait until task complete, but you are using the task wrong. First, you should never call ExecuteWork as it is internal method. You should use Start instead. Next code within task procedure will run in the background thread so when you call fTask.Start any code following that line will immediately run and it will not wait for task completion. The whole point of running a task is that it does not block further code along with the GUI. Next, since task procedure will run in background thread, you must never call Application.ProcessMessages within, because it can only be called within main thread context. And because task is running in the background you don't need to manually pump message queue anyway. If you wanted to use it to simulate some work, just use some other code. If you want to wait for task to complete you can call fTask.Wait, but this will then block the thread were it is called and if you call it on main thread it will block the main thread which defeats the purpose of running a task in the background. It only makes sense if user closes some form or similar and you need to wait for task to perform some cleanup. But in such scenarios you need to know that wait will be very short or you will get unresponsive application.

Maybe. But do you have proof that this is so. Do you have any proof that women like programming as much as men? If there are no gender differences then there should be way more women programmers than they are now. The percentage is just way to low that discrimination could be the only reason.

Because, even after initial selection in elementary school (where boys girls ration was 50:50) I was the only girl that went into tech oriented school, others went into social sciences or biology/chemistry/medicine. And then in high school there were more boys than girls from the beginning, where some classes were all boys and the rest were again 50:50. And from those 50:50 split classes (I think there was around 80 girls total), I was the only girl that pursued programming. And again, it was not that other girls couldn't code at all, but they were just not interested. I was the only one that spent nights behind the computer. Of course, there could be other factors, but I am pretty sure that in general women are just less attracted to coding than men. Again, I am not saying that they cannot do it, just that they are less attracted to such jobs. And again, I grew up in society that didn't have any obstacles for girls and women when choosing careers during education. I don't know if something changed in the meantime, but I doubt as my kids never reported that girls are having different treatment (and I asked them).

I have no problem with women plumbers, electricians, engineers, even astronauts (depending on a mission). But I would definitely draw the line with fighter pilots, or fire fighters and similar. The physical failure in critical moment can cost lives and not just theirs. We have to be real. There are plenty of jobs where physical fitness is required, but it is not absolutely critical. There are some jobs where it is. And again it is not that women couldn't do it, or that women shouldn't do it if there are no better fit men for the job, but I see equality being pushed in places where there is no place for it and where it could be dangerous because exceptional circumstances are part of the job and where physical strength is vital.

Well, I am pretty sure that women are less interested in coding in general. I have seen that both in my math-tech oriented high school and in math university. There were enough women there (even more in the university - about 40-50 %) and they were good in math (usually even better than men), but I was the only one in my generation (even several generations) that liked coding. Others all went into different directions. In high school everyone would come to me to help them with coding problems as I knew the most, almost my math and informatics teachers were women (only one man and he was the least competent one). So definitely there was no environmental pressure that would keep us away and I have never heard that girls or women cannot do math or code or anything like that.

I am sorry, but that is just not true. Women are generally physically weaker than men of same constitution and weight. I am talking about muscle strength, lung capacity, stamina. Again, I am not saying that there are no women that could work in some extreme conditions, but I think this is the wrong place to push equality. Imagine an accident in the mine, where men would be in better position to survive and also to help others.

Yes, there are definitely some jobs that are not meant for women. I am not saying that there are no women that can endure it, but in general jobs that require physical strength and stamina are not a good fit for women. It is a safety issue as they can more easily get hurt and could lack strength in critical moments and it is not just about them as there may be situations where others working with them can get hurt, too.

They just tried that and it was complete disaster https://meta.stackoverflow.com/questions/425162/we-are-seeking-functional-feedback-for-the-formatting-assistant

Probably rather low. Maybe a handful, unless we count all the Italian guys named Andrea and Danielle as women, too (PS those names are female in Croatia and it took me a while to find they are male names in Italy)

I am not questioning the number, but the explanation is moot. I have noticed that US folks (companies) have some strange desire to treat anyone outside of white male group as some sort of victims, which is both insulting and is not based in reality. I don't know, maybe women in US feel differently, but again, that has nothing to do with SO and moderation, but general culture. I have noticed that some people try to play victim card purely because it will give them advantage, and maybe some even think that is so, but that is something they need to fix on personal level. Also one of the explanations for low participation of women on SO is that they are afraid, but maybe they are just more thorough in their research and are better in solving problems on their own. I certainly used SO for years before I joined, but not because I was afraid, but simply because I didn't have the need to ask any questions. And when I joined I did that because I wanted to leave comment under one question about some high DPI bug, but then I needed 50 rep to do that, so I started answering... Point is, that anything is possible and it depends on each individual. Painting everyone with the same brush based on some completely unrelated characteristic is pure nonsense.

That is complete nonsense. Company loves analyzing their surveys by skewing context and seeing things that are not there. There is no barrier for entry for anyone based on who they are. Anyone can be as anonymous as they like or present themselves as they please. There are moderators with names UserXXXX.