Enough Thread to hang yourself



  • @Lorne Kates said:

    The oldest email should be on top
     

    Why? Gmail kind of puts the newest emails on top, as you may have noticed.

    I must be missing something here.

    Try making a joke, see if that works.



  • @morbiuswilters said:

    reading them and replying before the bot even got the damn email in the first place.
     

    So you're saying that your inner-platform "automation solution" was slower than using the next up layer of automation?

    Quaint!



  • @dhromed said:

    @morbiuswilters said:

    reading them and replying before the bot even got the damn email in the first place.
     

    So you're saying that your inner-platform "automation solution" was slower than using the next up layer of automation?

    Quaint!

    Goddamn you, I'm not even sure what this means, but I'm never again writing software out of the goodness of my heart.



  • @The Bytemaster said:

    @bridget99 said:

    Regarding the OP's narrative: I think a lot of people who've crafted multi-threaded programs might be surprised by the actual lack of real parallelism in their runtime result. That's a weakness of threading as a model of parallel computation : so much synchronization code ends up being necessary, and it's hard to find an optimal implementation. Hell, it's hard enough in many cases just to get everything working right.

    Obviously a JAVA programmer and not a .Net programmer.

    Threads have gotten better in every version of .Net... first, we had connection pooling built in from 1.0.  Then they added more threading capabilites in 2.0, 3.5 SP1, etc... 

    Now writing multi-threaded code is too easy.  You can overparallel your code and reduce prerformance.  I love being able to write parallel for each loops, spin a set of tasks off in parallel, or making a LINQ query against objects run on multiple threads by simply adding .AsParallel() to it.

    I'm more of a .NET programmer who doesn't give a crap. I didn't like .NET 3.0, or 3.5, and I was able to transition to an MFC role for a few years right when WPF, etc. were new. I started doing .NET again about 2 years ago. I admit, there is a lot I admire about LINQ, although I don't really use it. I know less about the parallelism stuff; do remember using anonymous methods to start threads in C#, and thinking that was handy. Unfortunately, most of the .NET I do now is VB.NET, and I've never quite figured out a lot of the VB syntax in this area, if it exists.



  • @morbiuswilters said:

    Goddamn you, I'm not even sure what this means, but I'm never again writing software out of the goodness of my heart.
     

    But how will I criticise your non-existent work then? You're so selfish.



  • @dhromed said:

    @morbiuswilters said:

    Goddamn you, I'm not even sure what this means, but I'm never again writing software out of the goodness of my heart.
     

    But how will I criticise your non-existent work then? You're so selfish.


    If it helps, you're welcome to criticize my open source projects. I'm not showing them to you, but you can use your imagination.


  • ♿ (Parody)

    @dhromed said:

    @Lorne Kates said:
    The oldest email should be on top

    Why? Gmail kind of puts the newest emails on top, as you may have noticed.

    I must be missing something here.

    In a particular conversation, the emails start with the oldest at the top. If you have it set to display in conversation mode. Dear God, why wouldn't you have it display in conversation mode?



  • @boomzilla said:

    @dhromed said:
    @Lorne Kates said:
    The oldest email should be on top

    Why? Gmail kind of puts the newest emails on top, as you may have noticed.

    I must be missing something here.

    In a particular conversation, the emails start with the oldest at the top. If you have it set to display in conversation mode. Dear God, why wouldn't you have it display in conversation mode?

    I always have newest on top, so I don't have to scroll down to see new emails.



  • @bridget99 said:

    If it helps, you're welcome to criticize my open source projects. I'm not showing them to you, but you can use your imagination.

    bridget99 left his laptop bag.

    [opens it]

    Hey! It's just filled with shredded newspaper!


  • Trolleybus Mechanic

    @boomzilla said:

    In a particular conversation, the emails start with the oldest at the top. If you have it set to display in conversation mode. Dear God, why wouldn't you have it display in conversation mode?
     

    Yup. Inbox is sorted newest on top, but Gmail groups them together in threads. Inside a thread, oldest on top. I use Gmail as a quasi forum reader-- latest activity bubbles up, I can read a thread at a glance. I'll click through if there's a lot of replies / I want to see everyone's avatar / have a deep seeded desire to get tagcloud raped.

    Edit: (hit post too soon).  Though I've been clicking through more often than not lately. CS is been schizophrenic as to when it sends out emails. And Gmail seems to randomly go batshit and split a "conversation" into two threads.  Not as in Message 1, 2, 3 NEW THREAD 4, 5, 6.  But Message 1, 2, 5, 8, NEW THREAD 3, 4, 7, 6



  • @boomzilla said:

    Dear God, why wouldn't you have it display in conversation mode?
     

    That doesn't work, because emails don't work that way. The email client basically makes a guess, and the result is a jumble of crap.



  • @Lorne Kates said:

    Gmail groups them together in threads
     

    Only if you tell it to.

    @Lorne Kates said:

    And Gmail seems to randomly go batshit and split a "conversation" into two threads.

    That's not Gmail's fault, that's your fault for thinking email can work like that. Emails are not linked data pieces like forum posts.

    @Lorne Kates said:

    latest activity bubbles up, I can read a thread at a glance.

    I use the New Posts pseudo-forum on here. It's very useful and I think reading this thread in a browser provides a better UX than almost-threaded email.

     

     



  • @bridget99 said:

    If it helps, you're welcome to criticize my open source projects. I'm not showing them to you, but you can use your imagination.
     

    Dear god, this is the best code I have ever seen in my entire life! It is so maintainable and works to well!

    ..oh

    ...oh wait sorry, heh, I had my own editor still open.

    *minimizes*

    ...

    EUGHGHGHG THIS IS WORSE THAN TWO GIRLS ONE CUP



  • @dhromed said:

    That's not Gmail's fault, that's your fault for thinking email can work like that. Emails are not linked data pieces like forum posts.

    Actually, they are, but almost nobody ever does it correctly. Gmail's threading is actually pretty decent, so I imagine the problem here is CS spitting out crap Message-IDs or not copying References to new emails correctly.


  • ♿ (Parody)

    @dhromed said:

    @boomzilla said:
    Dear God, why wouldn't you have it display in conversation mode?

    That doesn't work, because emails don't work that way. The email client basically makes a guess, and the result is a jumble of crap.

    Erm, except it isn't in gmail, so I'm not sure WTF you're talking about. It can get things wrong when you get a batch of emails like from CS, but that's a minor thing compared to how it keeps everything in a normal email thread (and even most CS messages) together.



  • @boomzilla said:

    Erm, except it isn't in gmail,
     

    That's why I used the word "client". ;)))

     

    I tried it once in Thunderbird. I saw a jumble of random forks and trees. I never went back. Linear every day.



  • @morbiuswilters said:

    Actually, they are,
     

    ohhh dam



  • @dhromed said:

    I tried it once in Thunderbird. I saw a jumble of random forks and trees. I never went back. Linear every day.

    Yeah, that's not uncommon. Usually because the sender effed up the Message-ID and References headers.

    The reason threading works so much better in Gmail is because they just use those headers as one part of their threading strategy. They are also able to infer from sender, subject, recipients, quoted content, time message was sent, which servers it was sent from, etc.. whether they are supposed to be in a single thread*. So you were actually probably right about Gmail "guessing" and that being why Lorne's threads were getting messed up.


    (*You can verify this yourself, if you like. Just use something like netcat or telnet to send very basic emails. Even without the Message-ID and References headers Gmail will thread the messages automatically if they come from the same sender. You may also need to make the subject the same, too, I can't remember.)


  • Trolleybus Mechanic

    Re: Fucking up Gmail

    @morbiuswilters said:

    You may also need to make the subject the same, too, I can't remember
     

    Yes, you do. For example, I just fucked up everyone's Gmail conversation for this thread.



  • @dhromed said:

    I tried it once in Thunderbird. I saw a jumble of random forks and trees. I never went back. Linear every day.

    WJFFM.

     



  • @DaveK said:

    WJFFM.
     

    Lies.



  • @morbiuswilters said:

    @Ben L. said:
    @morbiuswilters said:
    @Ben L. said:
    Example of why threading can be easy with the right tools

    Considering there is access to shared resources, this is hardly proof of anything. The same code in Java would hardly look different.

    Did you try running it?

    Yes, it prints strings, out-of-order. I'm not sure why you consider this an example of "why threading can be easy with the right tools", as it looks pretty much like the code in Java or C would look. It's so trivial it doesn't even delve into the actually thorny parts of threading, unless you consider out-of-order printing to be a threading issue. But in that case, the example is so arbitrary and silly, I'm not sure what it's even supposed to show.

    Here's a less silly example, stolen from the front page of golang.org.



  • @Ben L. said:

    Here's a less silly example, stolen from the front page of golang.org.

    I can't tell if you're being sarcastic, or you actually think this is a good example of using threads.



  • @Ben L. said:

    Here's a less silly example, stolen from the front page of golang.org.

    I have determined two things:

    1. I instantly hate go's syntax.

    2. You don't know what "less silly" means.



  • @morbiuswilters said:

    @bridget99 said:
    Regarding the OP's narrative: I think a lot of people who've crafted multi-threaded programs might be surprised by the actual lack of real parallelism in their runtime result. That's a weakness of threading as a model of parallel computation : so much synchronization code ends up being necessary, and it's hard to find an optimal implementation. Hell, it's hard enough in many cases just to get everything working right.

    [citation needed]


    Come on, I know it's not uncommon for newbies to screw up threading and make it essentially sequential with too much synchronization, but to claim the entire model is flawed is ridiculous. There is so much mutli-threaded software out there that will beat the CPU like a red-headed stepchild that your position is indefensible.

     

     

    this. plus in thus specific exampel it's trivial at least since Java 5. Just use an executor service with x threads and submit each job to i. AFAIK no sync needed at all between jobs. This is preferable anyway Instead of parallelizing an alogrothm it's much easier to just submit x nmber of jobs using a sequential algo.



  • @beginner_ said:

    @morbiuswilters said:

    @bridget99 said:
    Regarding the OP's narrative: I think a lot of people who've crafted multi-threaded programs might be surprised by the actual lack of real parallelism in their runtime result. That's a weakness of threading as a model of parallel computation : so much synchronization code ends up being necessary, and it's hard to find an optimal implementation. Hell, it's hard enough in many cases just to get everything working right.

    [citation needed]


    Come on, I know it's not uncommon for newbies to screw up threading and make it essentially sequential with too much synchronization, but to claim the entire model is flawed is ridiculous. There is so much mutli-threaded software out there that will beat the CPU like a red-headed stepchild that your position is indefensible.

     

     

    this. plus in thus specific exampel it's trivial at least since Java 5. Just use an executor service with x threads and submit each job to i. AFAIK no sync needed at all between jobs. This is preferable anyway Instead of parallelizing an alogrothm it's much easier to just submit x nmber of jobs using a sequential algo.

    If by "exampel" you mean that Go program, you may be right. I haven't really read through it. BUT- I am thoroughly skeptical of any argument that "you can just use
    (whatever) and you really don't ever have to worry about synchronization." I've heard people say that about message passing, .NET TPL, etc., and I just don't buy it. Parallelism will often increase the costs associated with achieving/proving correctness. Overlooking this is a classic error among beginners.


  • Considered Harmful

    @bridget99 said:

    Parallelism will often increase the costs associated with achieving/proving correctness.

    You guys, I think I've got the brainworms where bridget seems like he's making sense.

    Please, you have to shoot me.


Log in to reply