The.NET standard libraries exist in several profiles -- "Core", "Client", "Full".
People today write their libraries under the "Core" profile so that they work equally well on any platform -- Silverlight, desktop, phone. Core contains the common standard libraries -- e.g. things like StringBuilder, LINQ, generic collections, and the other day-to-day programming side. "Client Profile" also contains UI stuff, and "Full Profile" also contains server stuff.
For Metro, you will use APIs from both.NET Core Profile and from WinRT. WinRT will provide things like local storage APIs and UI. Core Profile will provide all the other stuff.
NB. I'm on the C#/VB language design team at Microsoft.
Parse your code in the background, generate symbol tables, maintain complete symbols of every class in your program, generate bound method trees at least of the current method you're on and usually others, provide intellisense, refactoring, scan your code for usage or other stylistic errors, colorize,...
I think you're reading the surface words rather than the universally-understood subtext.
It's like when a scientific paper says "We were unable to replicate the results of Jones et al".
This doesn't mean "we were unable to replicate the results of Jones et al". Instead it means "Jones et al were either a bunch of nincompoops who didn't understand what they were doing, or they actively falsified their work".
Or when you call someone a poopie-head. It doesn't mean you think their head is made of poop; it means you don't like them.
How would marinas need to change? They all already have to deal with tides. I haven't seen any that are built with exactly zero tolerance for the highest of high tides.
(The original RedHat complaint was that "MadeForWin8" machines must support UEFI, and must include Microsoft's boot keys; RedHat were worried that BIOS makers would ship with this bare minimum of support, i.e. not allowing you to disable UEFI or to add your own keys.) Disclaimer: I work at MS as a language designer.
Indeed, if you factor your code into one module for the core logic, and another for the UI, then the core logic module will work exactly as is on Windows8/x86, on Windows8/ARM, on web-servers running ASP, on Windows Phones, on Silverlight web-pages, even on the "NETDUINO" chip used by hobbyists for building electronics. It doesn't even need to be recompiled -- the same DLL works on all.
(MS recently released the "Portable Framework", i.e. that subset of the complete.NET framework that's found on all these systems, and your core logic DLL will be written against this rather than any one latform).
The DLR is still very much there, present and supported in VS2010 and in the Win8 developer preview.
(It's right there every time you use the "dynamic" keyword in C#, or if you invoke a late-bound method from VB on any object that implements IDynamicMetaObjectProvider e.g. the DOM from Silverlight). NB. I'm on the VB/C# team at Microsoft.
I may be deluded, but I certainly don't believe that Algeria, Romania or Peru have done that (to pick a few of the 50th largest countries ranked by GDP). I think their intelligence departments just aren't that well financed or modernized.
I think we could already map the underlying topology just fine -- using radar, since it penetrates through the ice. I remember back in the early 1990s, on a school trip to the Scott Polar Research Institute, that they showed us a topological map of Antarctica.
Another advantage which they omitted from the article -- this invention will help you insert the plug the right way round.
With the current circular 3.5mm jacks, it's actually impossible to know whether you've rotated the plug correctly. Sure, you can try to figure out if you've got it right by listening to the resultant sound quality, but that's inexact and most people don't even have the equipment. Now with Apple's invention, everyone will be able to insert it with the right rotation -- first time, and every time.
It sounds like what you're describing has always been the way that WOW worked. The game hasn't "gone off", gone passed its prime, like food left out of the refrigerator. What you're describing sounds like a maturing process in YOU rather than the game...
Where in Europe? When I was in Italy last October, WP7 was the single most common smartphone I saw on the streets, and every billboard was plastered with Italy's national telecom operator advertising it. (disclaimer: I work at MS).
You've completely misunderstood how "first-to-file" works.
If you describe your invention in detail on the internet, then this counts as published prior art. No one can patent it. Even if a company never saw your post on the internet, and they are first to file -- well, the prior art means that they won't get the patent.
However, if you kept your invention completely secret, and another company invented the same thing a year later and filed for it, then they'd be granted their patent. That's because there was no published prior art.
For the introduction of all road safety devices, people seem to adjust their behavior to be correspondingly more dangerous, to end up with the same overall risk level. Wikipedia cites studies on ABS, seatbelts, bicycle helmets &c. If the increased danger of cellphones didn't follow the same pattern, it would be very surprising.
GP: As for your red Xs, I suggest you paste special any content that isn't coming from an image file and select Picture (enhanced metafile).
I definitely would NOT use Enhanced Metafiles (EMFs). Use Windows Metafiles (WMFs) instead.
My experience with writing latexEMF/WMF conversion a decade ago was that no applications had a really good grasp on EMFs -- on their dimensions, scaling factors, colors. Even today I observe that pictures copy/pasted from R into Excel2003 as EMF get their colors and cropping messed up when moving to Excel2010.
Sure, EMFs are new and 32bit while WMFs are boring old 16bit, and EMFs have some extra capabilities, but it's not worth it.
As a developer and program-manager, I use HTML for most of my email...
* When I'm sending code snippets, it's nice to have them colorized * When I'm sending a list of feature options along with their pros/cons, it's nice to tabulate this * When I'm sending normal prose, it's nice to use italic/bold * When I'm sending a list of bugs, it's nice to make that a table * When I'm sending action items, it's nice to highlight the "Must Act Now" recipient's name in yellow * When I'm reporting bugs, it's nice to have screenshots in the email so I can write around them (rather than just referring to attachments by name)
Oh, and I'd prefer to write a numbered list in HTML rather than text, since that way it will wrap+flow properly on receipients' screens.
The dirty secret of parallel programming is that it's *NOT* so widely needed. I think a lot of academics got funding to study automatic parallelization or other parallel techniques, and they latch on to multicore as a justification for it, but it's not.
There is only one GOOD reasons to use multithreading -- because your work is compute-bound. This typically happens on large-data applications like audio/video processing (for which you just call out to libraries that someone else has written), or else on your own large-data problems that have embarrassingly trivial parallelization: e.g.
var results = from c in Customers.AsParallel() where c.OrderStatus="unfilfilled" select new {Name=c.Name, Cost=c.Cost};
Here, using ParallelLINQ, it's as simple as just sticking in "AsParallel()". The commonest sort of large-data problems don't have any complicated scheduling.
There are also BAD reasons why people have used multithreading, particularly to deal with long-latency operations like network requests. But this is a BAD reason, and you shouldn't use multithreading for it. There are better alternatives, as shown by the Async feature in F#/VB/C# which I worked on, which was also copied into Javascript with Google's traceur compiler). e.g.
Task task1 = (new WebClient()).DownloadStringTaskAsync("http://a.com"); Task task2 = (new WebClient()).DownloadStringTaskASync("http://b.com"); Task winner = await Task.WhenAny(task1,task2); string result = await winner;
Here it kicks off two tasks in parallel. But they are cooperatively multitasked on the same main thread at the "await" points. Therefore there is *NO* issue about race conditions; *NO* need to use semaphores/mutexes/condition-variables. The potential for unwanted interleaving is dramatically reduced.
So in the end, who are the people who still need to develop multithreaded algorithms? There are very few. I think they're just the people who write high-performance multithreaded libraries.
To be honest it means we cannot tax corporations. Every dollar a corporation pays in taxes comes from its customers, that means we pay those dollars.
Also, to be honest, it means we cannot tax individuals. Every dollar an individual pays in taxes comes from his paycheck, that means the corporations pay those dollars.
Slashdot Mirror
That's not quite right.
The .NET standard libraries exist in several profiles -- "Core", "Client", "Full".
People today write their libraries under the "Core" profile so that they work equally well on any platform -- Silverlight, desktop, phone. Core contains the common standard libraries -- e.g. things like StringBuilder, LINQ, generic collections, and the other day-to-day programming side. "Client Profile" also contains UI stuff, and "Full Profile" also contains server stuff.
For Metro, you will use APIs from both .NET Core Profile and from WinRT. WinRT will provide things like local storage APIs and UI. Core Profile will provide all the other stuff.
NB. I'm on the C#/VB language design team at Microsoft.
And the other stuff that Eclipse does...
Parse your code in the background, generate symbol tables, maintain complete symbols of every class in your program, generate bound method trees at least of the current method you're on and usually others, provide intellisense, refactoring, scan your code for usage or other stylistic errors, colorize, ...
I think you're reading the surface words rather than the universally-understood subtext.
It's like when a scientific paper says "We were unable to replicate the results of Jones et al".
This doesn't mean "we were unable to replicate the results of Jones et al". Instead it means "Jones et al were either a bunch of nincompoops who didn't understand what they were doing, or they actively falsified their work".
Or when you call someone a poopie-head. It doesn't mean you think their head is made of poop; it means you don't like them.
Incorrect. It's pronounced BOLL-ON-YA
How would marinas need to change? They all already have to deal with tides. I haven't seen any that are built with exactly zero tolerance for the highest of high tides.
I have NEVER seen a BIOS with minimal features.
(The original RedHat complaint was that "MadeForWin8" machines must support UEFI, and must include Microsoft's boot keys; RedHat were worried that BIOS makers would ship with this bare minimum of support, i.e. not allowing you to disable UEFI or to add your own keys.) Disclaimer: I work at MS as a language designer.
Yes, .NET does take care of this.
Indeed, if you factor your code into one module for the core logic, and another for the UI, then the core logic module will work exactly as is on Windows8/x86, on Windows8/ARM, on web-servers running ASP, on Windows Phones, on Silverlight web-pages, even on the "NETDUINO" chip used by hobbyists for building electronics. It doesn't even need to be recompiled -- the same DLL works on all.
(MS recently released the "Portable Framework", i.e. that subset of the complete .NET framework that's found on all these systems, and your core logic DLL will be written against this rather than any one latform).
NB. I work at MS on the VB/C# language team.
The DLR is still very much there, present and supported in VS2010 and in the Win8 developer preview.
(It's right there every time you use the "dynamic" keyword in C#, or if you invoke a late-bound method from VB on any object that implements IDynamicMetaObjectProvider e.g. the DOM from Silverlight). NB. I'm on the VB/C# team at Microsoft.
I may be deluded, but I certainly don't believe that Algeria, Romania or Peru have done that (to pick a few of the 50th largest countries ranked by GDP). I think their intelligence departments just aren't that well financed or modernized.
I think we could already map the underlying topology just fine -- using radar, since it penetrates through the ice. I remember back in the early 1990s, on a school trip to the Scott Polar Research Institute, that they showed us a topological map of Antarctica.
Another advantage which they omitted from the article -- this invention will help you insert the plug the right way round.
With the current circular 3.5mm jacks, it's actually impossible to know whether you've rotated the plug correctly. Sure, you can try to figure out if you've got it right by listening to the resultant sound quality, but that's inexact and most people don't even have the equipment. Now with Apple's invention, everyone will be able to insert it with the right rotation -- first time, and every time.
How is any of this "past its prime" ?
It sounds like what you're describing has always been the way that WOW worked. The game hasn't "gone off", gone passed its prime, like food left out of the refrigerator. What you're describing sounds like a maturing process in YOU rather than the game...
I've definitely read studies in the past which show connections between self-reported preference and actual preference. Quite a few of them.
Did you check whether this study cited such a thing? or whether it's an accepted base part of this area's research field by now?
The things you're talking about -- long-term acceptability -- I agree they're important but wouldn't call them "actual preference".
Where in Europe? When I was in Italy last October, WP7 was the single most common smartphone I saw on the streets, and every billboard was plastered with Italy's national telecom operator advertising it. (disclaimer: I work at MS).
The UK Nuclear Commissioning Authority estimates about $6 billion per site to decommission, http://en.wikipedia.org/wiki/Nuclear_decommissioning.
(I don't know how to reconcile this with apparent US costs of under $1 billion per site.)
You've completely misunderstood how "first-to-file" works.
If you describe your invention in detail on the internet, then this counts as published prior art. No one can patent it. Even if a company never saw your post on the internet, and they are first to file -- well, the prior art means that they won't get the patent.
However, if you kept your invention completely secret, and another company invented the same thing a year later and filed for it, then they'd be granted their patent. That's because there was no published prior art.
The phrase "email retention policies" is double-speak. It should be "email deletion policies".
Presumably so...
http://en.wikipedia.org/wiki/Risk_compensation
For the introduction of all road safety devices, people seem to adjust their behavior to be correspondingly more dangerous, to end up with the same overall risk level. Wikipedia cites studies on ABS, seatbelts, bicycle helmets &c. If the increased danger of cellphones didn't follow the same pattern, it would be very surprising.
GP: As for your red Xs, I suggest you paste special any content that isn't coming from an image file and select Picture (enhanced metafile).
I definitely would NOT use Enhanced Metafiles (EMFs). Use Windows Metafiles (WMFs) instead.
My experience with writing latexEMF/WMF conversion a decade ago was that no applications had a really good grasp on EMFs -- on their dimensions, scaling factors, colors. Even today I observe that pictures copy/pasted from R into Excel2003 as EMF get their colors and cropping messed up when moving to Excel2010.
Sure, EMFs are new and 32bit while WMFs are boring old 16bit, and EMFs have some extra capabilities, but it's not worth it.
As a developer and program-manager, I use HTML for most of my email...
* When I'm sending code snippets, it's nice to have them colorized
* When I'm sending a list of feature options along with their pros/cons, it's nice to tabulate this
* When I'm sending normal prose, it's nice to use italic/bold
* When I'm sending a list of bugs, it's nice to make that a table
* When I'm sending action items, it's nice to highlight the "Must Act Now" recipient's name in yellow
* When I'm reporting bugs, it's nice to have screenshots in the email so I can write around them (rather than just referring to attachments by name)
Oh, and I'd prefer to write a numbered list in HTML rather than text, since that way it will wrap+flow properly on receipients' screens.
I'm reading your citation, but it doesn't seem to support your claim... HULL LOSS ACCIDENTS:
A320: 0.34 per million departures
737-300/400/500: 0.52 per million departures
737-600/700/800/900: 0.21 per million departures
A330: 0.27 per million departures
767: 0.39 per million departures
777: 0.21 per million departures
A380: too few to judge
747-400: 0.49 per million departures
It looks like, in each class, the airbus is better than the old boeings, but not as good as the new boeings.
The dirty secret of parallel programming is that it's *NOT* so widely needed. I think a lot of academics got funding to study automatic parallelization or other parallel techniques, and they latch on to multicore as a justification for it, but it's not.
There is only one GOOD reasons to use multithreading -- because your work is compute-bound. This typically happens on large-data applications like audio/video processing (for which you just call out to libraries that someone else has written), or else on your own large-data problems that have embarrassingly trivial parallelization: e.g.
var results = from c in Customers.AsParallel() where c.OrderStatus="unfilfilled" select new {Name=c.Name, Cost=c.Cost};
Here, using ParallelLINQ, it's as simple as just sticking in "AsParallel()". The commonest sort of large-data problems don't have any complicated scheduling.
There are also BAD reasons why people have used multithreading, particularly to deal with long-latency operations like network requests. But this is a BAD reason, and you shouldn't use multithreading for it. There are better alternatives, as shown by the Async feature in F#/VB/C# which I worked on, which was also copied into Javascript with Google's traceur compiler). e.g.
Task task1 = (new WebClient()).DownloadStringTaskAsync("http://a.com");
Task task2 = (new WebClient()).DownloadStringTaskASync("http://b.com");
Task winner = await Task.WhenAny(task1,task2);
string result = await winner;
Here it kicks off two tasks in parallel. But they are cooperatively multitasked on the same main thread at the "await" points. Therefore there is *NO* issue about race conditions; *NO* need to use semaphores/mutexes/condition-variables. The potential for unwanted interleaving is dramatically reduced.
So in the end, who are the people who still need to develop multithreaded algorithms? There are very few. I think they're just the people who write high-performance multithreaded libraries.
Timing: I don't know about goat, but with lamb, it takes 30 seconds to die after you slit its throat.
Pain: I don't know. The lamb I slaughtered didn't struggle much. I wonder if it's calm like when people slit their wrists in the bath, or agonizing?
To be honest it means we cannot tax corporations. Every dollar a corporation pays in taxes comes from its customers, that means we pay those dollars.
Also, to be honest, it means we cannot tax individuals. Every dollar an individual pays in taxes comes from his paycheck, that means the corporations pay those dollars.
They dug the tunnel because it was there