Empowering kids, women, minorities?? That's ridiculous. App Inventor's biggest problem is that it is too low-level. There is almost a one-to-one correspondence between every block in App Inventor and a single Java keyword or operator. Therefore there is NOTHING you can learn with App Inventor that you can't learn by learning to write source code. In fact the blocks themselves obscure meaning, because their visual representation doesn't convey much actual meaningful information. App Inventor could have been really, really good if it worked at a much higher level, and if the construction process wasn't so highly geometrically constrained and brittle.
I have been wondering if switching to using a tiny IP packet size would fix the problem, by minimizing the number of wireless collisions. My theory is that if my packets are much smaller than anybody else's, they will have a higher chance of getting through. Has anybody tried this?
I have been wondering lately if switching to using a tiny IP packet size would fix the problem, by minimizing the number of aborted packets due to random wireless collisions. My theory is that if my packets are much smaller than anybody else's, they will have a higher chance of getting through. Has anybody tried this?
Sometimes switching to Google's DNS servers at 8.8.8.8 or 8.8.4.4 and/or using a local DNS caching server rather than using whatever DNS server is provided to you via DHCP can solve the problem (because sometimes the heavy traffic is causing greater problems with local DNS server overload than with wireless packet collisions etc.).
One could conclude that Mozilla has no idea at this point what people are expecting from a 64-bit version of Firefox, so Dotzler is asking for some feedback.
That's ridiculous. I think that people just want Firefox to *work* on their latest computer, and they don't want to care about either "how many bits their computer has" or whether their OS is 32 or 64 bit or whether the version of Firefox they just downloaded is 32 or 64 bits. Why even ask questions like what people expect from a 64-bit build?
The times I have heard Peter Thiel speak in person, I have been decidedly unimpressed. He's one of the guys that got lucky, he's not where he is because of genius. So of course he's going to reject college education, he didn't need one to get where he is.
D-Wave has been beating this drum for years -- and/or the press has been conveying the message incorrectly. What they have produced is *not* a quantum computer. They have only proved for symmetric satisfiability problems that it runs in polynomial time, not in the general case -- and I would be interested to see one real-world problem it can actually solve (I doubt they have actually built what is described in the original computing by adiabatic evolution paper from 2000).
I have run many versions of CM (even contributed to CM early on) and many versions of stock. My conclusion: CM breaks a heck of a lot more than it fixes -- and the community is more likely than not just going to get mad at you or ignore you if you try to report bugs. Extremely unfriendly, unhelpful community. Since about Eclair, CM has *not* been better than stock.
I'm just glad I didn't check the results until after the website became inaccessible. I'd rather not go through what you and your girlfriend went through. Will be checking back on July 15th for sure -- but now I have to wonder if their programmers are competent at all.
I'm less concerned that this kid was pulled up on charges of psychologically hurting 50 girls in his school and perpetuating a culture of bullying (which is terrible, speaking as one who was bullied extensively), and in some weird way more concerned that Mark Zuckerberg not only did Hot or Not at Harvard and got away with it, but has now enabled that sort of cyberbullying for about 1 billion people (either directly, or indirectly through Fear Of Missing Out, FOMO)...
No, in a UI-based program that reacts to a user's actions or its own internal timers in an event loop, everything speed-related has to do with the turnaround time between an event firing (a user click, a URL being entered, or a JS timer going off) and the result of that event being displayed to the user -- i.e. latency. So latency is really just the inverse of "bandwidth" or "speed" as you put it, within the UI paradigm.
faster => decreased latency.
sluggish => decreased latency.
Well in multicore processors (I use a 24-core machine almost every day for my work), the percentage of silicon that is "dark" as defined by TFA ("Dark silicon is a portion of a microchip that is left unused") is increasingly just general purpose computing hardware (instruction pipeline, ALU, non-shared cache etc.) that belongs to cores that are sitting idle, i.e. it's not specific hardware that implements unusual vector instructions or anything like that, it's due to entire cores being unused. In that sense the response you criticized exactly answers the original problem by dealing with the problem of making optimal use of all the available cores in a machine with zero increased programmer effort due to proper language support for implicit parallelization. Currently vaporware, yes, because it is in the design stage. But it very much deals with dark silicon, specifically the multicore aspect of the problem.
You can create memory in "arenas" (an overloaded word, unfortunately) where the entire arena is freed at once. e.g. you can create a graph as a collection of nodes that can have arbitrary inter-connectivity. When the the last reference to anything in the collection is dropped, the whole collection is freed. This will cover a lot of cases with circular deps.
Slashdot Mirror
As always, if you think you're too old to learn, you're right. But until then, learn Scala.
Empowering kids, women, minorities?? That's ridiculous. App Inventor's biggest problem is that it is too low-level. There is almost a one-to-one correspondence between every block in App Inventor and a single Java keyword or operator. Therefore there is NOTHING you can learn with App Inventor that you can't learn by learning to write source code. In fact the blocks themselves obscure meaning, because their visual representation doesn't convey much actual meaningful information. App Inventor could have been really, really good if it worked at a much higher level, and if the construction process wasn't so highly geometrically constrained and brittle.
I read this as "SETI Finds Funds For the Alien Telescope Array"...
I have been wondering if switching to using a tiny IP packet size would fix the problem, by minimizing the number of wireless collisions. My theory is that if my packets are much smaller than anybody else's, they will have a higher chance of getting through. Has anybody tried this?
I have been wondering lately if switching to using a tiny IP packet size would fix the problem, by minimizing the number of aborted packets due to random wireless collisions. My theory is that if my packets are much smaller than anybody else's, they will have a higher chance of getting through. Has anybody tried this?
Sometimes switching to Google's DNS servers at 8.8.8.8 or 8.8.4.4 and/or using a local DNS caching server rather than using whatever DNS server is provided to you via DHCP can solve the problem (because sometimes the heavy traffic is causing greater problems with local DNS server overload than with wireless packet collisions etc.).
UAVs lighter than 50lb are (mostly) unregulated in the US right now.
I thought this is the sort of thing the DA's office was for?
One could conclude that Mozilla has no idea at this point what people are expecting from a 64-bit version of Firefox, so Dotzler is asking for some feedback.
That's ridiculous. I think that people just want Firefox to *work* on their latest computer, and they don't want to care about either "how many bits their computer has" or whether their OS is 32 or 64 bit or whether the version of Firefox they just downloaded is 32 or 64 bits. Why even ask questions like what people expect from a 64-bit build?
A name like i4i is inviting Microsoft to take an eye for an eye and sue them right back.
The times I have heard Peter Thiel speak in person, I have been decidedly unimpressed. He's one of the guys that got lucky, he's not where he is because of genius. So of course he's going to reject college education, he didn't need one to get where he is.
D-Wave has been beating this drum for years -- and/or the press has been conveying the message incorrectly. What they have produced is *not* a quantum computer. They have only proved for symmetric satisfiability problems that it runs in polynomial time, not in the general case -- and I would be interested to see one real-world problem it can actually solve (I doubt they have actually built what is described in the original computing by adiabatic evolution paper from 2000).
Also, the average user will pretty much not know or notice *any* improvement by running CM, if they already have Gingerbread.
I have run many versions of CM (even contributed to CM early on) and many versions of stock. My conclusion: CM breaks a heck of a lot more than it fixes -- and the community is more likely than not just going to get mad at you or ignore you if you try to report bugs. Extremely unfriendly, unhelpful community. Since about Eclair, CM has *not* been better than stock.
I'm just glad I didn't check the results until after the website became inaccessible. I'd rather not go through what you and your girlfriend went through. Will be checking back on July 15th for sure -- but now I have to wonder if their programmers are competent at all.
I'm less concerned that this kid was pulled up on charges of psychologically hurting 50 girls in his school and perpetuating a culture of bullying (which is terrible, speaking as one who was bullied extensively), and in some weird way more concerned that Mark Zuckerberg not only did Hot or Not at Harvard and got away with it, but has now enabled that sort of cyberbullying for about 1 billion people (either directly, or indirectly through Fear Of Missing Out, FOMO)...
(Accepting physical objects as gifts when you're Julian Assange) = (bad idea).
You can't help but think that this is the way all programming will be done in the future.
I hate statements like that.
All I can think of is, how many people on his team work with the same two test devices? Ewwwww..
Typo: less sluggish => decreased latency.
No, in a UI-based program that reacts to a user's actions or its own internal timers in an event loop, everything speed-related has to do with the turnaround time between an event firing (a user click, a URL being entered, or a JS timer going off) and the result of that event being displayed to the user -- i.e. latency. So latency is really just the inverse of "bandwidth" or "speed" as you put it, within the UI paradigm.
faster => decreased latency.
sluggish => decreased latency.
Wow.
Great explanation, thanks.
Well in multicore processors (I use a 24-core machine almost every day for my work), the percentage of silicon that is "dark" as defined by TFA ("Dark silicon is a portion of a microchip that is left unused") is increasingly just general purpose computing hardware (instruction pipeline, ALU, non-shared cache etc.) that belongs to cores that are sitting idle, i.e. it's not specific hardware that implements unusual vector instructions or anything like that, it's due to entire cores being unused. In that sense the response you criticized exactly answers the original problem by dealing with the problem of making optimal use of all the available cores in a machine with zero increased programmer effort due to proper language support for implicit parallelization. Currently vaporware, yes, because it is in the design stage. But it very much deals with dark silicon, specifically the multicore aspect of the problem.
You can create memory in "arenas" (an overloaded word, unfortunately) where the entire arena is freed at once. e.g. you can create a graph as a collection of nodes that can have arbitrary inter-connectivity. When the the last reference to anything in the collection is dropped, the whole collection is freed. This will cover a lot of cases with circular deps.