Dalija Prasnikar

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.

I have no idea what you are trying to say.

Don't give them more bad ideas. It is not that AI cannot be used for moderation, but at this point I am pretty sure it will be used in wrong way.

The whole situation at Stack Overflow just made a drastic turn for the worse: https://meta.stackoverflow.com/questions/425162/we-are-seeking-functional-feedback-for-the-formatting-assistant and https://meta.stackoverflow.com/questions/425081/stack-overflow-will-be-experimenting-with-a-question-formatting-assistant-and-w It seems that whole reason behind tying the mods hands when it comes to detecting and moderating AI content is related to the brand new "AI Formatting Assistant" It is presented as something that would help people write better questions, but I guess that is just first step and second one would be expanding it to answers, too. Because such "formatted" posts would have typical AI signature, moderators would not be able to distinguish between AI generated and "merely formatted" posts. Additionally, the results of "formatting" go beyond mere formatting because AI completely rewrites the post including text and code adding its hallucinations on top. It is beyond horrible and harmful.

Strike update: https://meta.stackexchange.com/questions/390106/moderation-strike-update-data-dumps-choosing-representatives-gpt-data-and-wh

The problem is that all variants of IGenericList<T> have same GUID so Supports function will succeed even though those different generic lists are not compatible.

There is not bug in compiler, but in your code. When you say LCastedList.Add(TAncestorObject.Create) What will happen is equivalent of following code: var Tmp: IInterface := TAncestorObject.Create; LCastedList.Add(Tmp); This will be because LCastedList is declared as IGenericList<IInterface> and stores IInterface references. However when you retrieve stored reference you will call that on original list which is declared as IGenericList<IAncestorObject> and retrieved reference will be of type IAncestorObject and you can try to call LObj.ID on that retrieved reference. But in reality stored reference was IInterface, not IAncestorObject and it crashes when you call ID on it because that method (GetID) it simply does not exist there. Point of generics is that you have same type stored in the background, not to store incompatible types. even though there is same object behind those two interface references, those interfaces are completely different types represent different entry points to that object. Sometimes you can force "wrong" type to be stored at runtime, which is usually not what you should be doing, but if you do, you need to make sure that every time you retrieve something that might be "wrong" you cast it back to appropriate type. var LTmp := LList.First; var LObj: IAncestorObject; if Supports(LTmp, IAncestorObject, LObj) then var LID := LObj.ID ;

LSP is separate process and it's memory consumption does no affect the IDE. Extracting that functionality outside and reducing IDE memory footprint was one of the reasons LSP was introduced in the first place. There is known GDI handle leak in Parnassus Navigator https://quality.embarcadero.com/browse/RSP-40986 Also IDE is using a bit more GDI handles than it used to and it seems that it has some caching issues, where it caches the component icons but it does not have a cache limit and it does not release those that were not accessed in for some period of time. Opening plenty of forms and accessing many different components during design time can hit GDI handle limit. AFAIK you can increase that limit (I never had issues so I never tried it) https://stackoverflow.com/questions/38612364/how-to-increase-the-maximum-amount-of-gdi-object-for-windows-10