Jump to content

Dalija Prasnikar

Members
 View Profile  See their activity

  • Content Count

    1061

  • Joined

  • Last visited

  • Days Won

    91

Posts posted by Dalija Prasnikar

  3. Posted

    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.

    • Thanks 1

  4. Posted

    10 hours ago, Jud said:

    Also, I just realized that I made a mistake.  I was using tThread.synchronize in one place and tThread.queue in another place, writing to the same memo, and the data was not matching.  It seems that thread.queue is NOT thread-safe for doing this.

    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.

  5. Posted

    1 hour ago, Jud said:

    I need to write to a memo on the main form from within a thread.  In an old program using tasks I was doing this:

     

    tThread.synchronize( tThread.current, procedure
    begin
      form1.TestMemo.lines.add( 'Testing ');
      application.ProcessMessages;
    end);

     

    You should remove Application.ProcessMessages from that code as it serves no purpose. 

     

    1 hour ago, Jud said:

    and it was working.  I put the same type of thing in a tread called by the parallel for, but it isn't writing to the memo. 

     

    Is there a different way to do it from a thread called from a parallel for? 

     

    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.

  6. Posted

    2 hours ago, bravesofts said:

     Why  Method ExecuteWork  Fail in mobile device (especially ANDROID) ?

    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. 

    2 hours ago, bravesofts said:

      Please don't tell me that Method : ExecuteWork is not a regular or illegal or what ever else ... otherwhise why the EMB Group add it inside the interface ITASK ?

    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.

     

    • Like 3

  7. Posted · Edited by Dalija Prasnikar

    34 minutes ago, bravesofts said:

    is it impossible to create threads in mobile devices while avoiding the main app thread from going to the next line of code until tasks complete ?

    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;

     

    • Like 1

  8. Posted

    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. 

  9. Posted

    20 minutes ago, bravesofts said:

    Not block the main thread in that definition... !!!

    I think the stupid sleep function is the unsafe way to block main thread... 

     

    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.

    20 minutes ago, bravesofts said:

    I mean block main thread using the safe way like executeWork does... 

    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.

    20 minutes ago, bravesofts said:

    Delphi does not support background threads in Android and iOS devices where the main thread wait smoothly and safe... 

    Again, it is not about Delphi, it is that this is the wrong way to use threads. 

    • Like 1

  10. Posted

    11 minutes ago, bravesofts said:

    I simply if I Don't use itask.ExecuteWork; and use the regular  Start; 

    The main thread App will not wait for task completion and execute the next line code...   

    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;

     

    11 minutes ago, bravesofts said:

    But with executeWork I succeeded to force main thread App to wait smoothly without freezing the app.... 

    I don't like use sleep function inside while loop in order to execute background thread... 

    If you change your code workflow, you will not need the Sleep or anything else.

    11 minutes ago, bravesofts said:

    Try to use my wrong code (like I said before it's not complete...) in VCL and FMX windows example and you will find the magic of executeWork method.. 

    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. 

    • Like 1

  12. Posted

    2 hours ago, bravesofts said:

    Maybe help to understand my request.. 

    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.

     

    52 minutes ago, bravesofts said:

    Is there any solution targeting the mobile devices!! 

    ----

    I'm afraid that :

    Delphi does not support background threads in Android and iOS devices !!

    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.

    • Like 1

  13. Posted

    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.

    • Like 1

  14. Posted · Edited by Dalija Prasnikar

    25 minutes ago, David Heffernan said:

    This is classic correlation / causation territory

    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.

  15. Posted

    8 minutes ago, David Heffernan said:

    How did you determine that this difference was due to gender and not some other reason? Personal anecdotes prove little.

    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).

  16. Posted

    7 minutes ago, Lars Fosdal said:

    Yet, women are fighter pilots, front line soldiers, astronauts, mountain climbers, race car drivers, plumbers, electricians, engineers, and what not.

    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.

    7 minutes ago, Lars Fosdal said:

    IMO, equality is about more than comparing physical traits. It is about mentality, attitude and equal opportunities.

    I think it is good for any industry to have a balanced work force, hence we need to find out why there are less female programmers, and not bury our heads in the sand, like SO did with their yearly polls.

    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.

    • Like 1

  17. Posted

    1 minute ago, David Heffernan said:

    "I'm sure". How are you sure? 

    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. 

  18. Posted

    2 minutes ago, Lars Fosdal said:

    Apart from the ability to exert physical strength (not including my niece who is a strongwoman national champion), women are no less fit than men to work in difficult or demanding enviroments.

    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. 

  19. Posted

    8 minutes ago, Fr0sT.Brutal said:

    And that restriction could have been caused by the care of women's health. Conditions in mines are really heavy even for strong men.

    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.

  22. Posted · Edited by Dalija Prasnikar

    30 minutes ago, Lars Fosdal said:

    Yet, the 2022 survey statistics shows that less than 1 in 10 of the responding users are female.

    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.

    • Like 7

  23. Posted

    2 minutes ago, Lars Fosdal said:

    https://www.wired.com/story/stack-overflow-gender-problem/ and there is this... 
    Can the moderation be a factor when women, minorities and non-native english speakers are put off by SO?

    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.

    • Like 3
×