Sunday, December 4, 2011

Building a PC, Part VII: Rebooting

I've had more or less the same PC, with various updates, since 2007. I've written about most of it here:

While the advice in those original articles is still quite sound, my old 2007 era case was feeling mighty creaky. I needed a new chassis. I also wanted a motherboard that supported native 6 Gbps SATA for the latest generation of SSDs that truly benefit from them. The buzz around the Sandy Bridge based Core i7-2600k was nearly deafening, and I've fallen completely in love with my last HTPC build based on the same technology. (Oh, and even if you already read that article, read it again because I added new PicoPSU and case information that takes it from awesome to sublime – on the order of 17 watts idle!)

So I decided it was time to build myself a nice Sandy Bridge system. What I ended up with is easily the best case and motherboard combination I've ever laid hands on. Read on!

I cut out a lot of the initial research work by relying on my old, dear friends at Tech Report and their current workstation recommendations:

As for the case, I was impressed by the Tech Report review of the Corsair 600T, which even comes in a heart-stopping pseudo stormtrooper white. WANT.

Corsair-600t-special-edition

When it comes to power supplies, I'm crazy about efficiency, and fortunately there are now lots of so-called "80 Plus Gold" PSUs out there now, offering a staggering 90% efficiency under most loads. Power supply efficiency is important, because the rest of that heat is dumped back into your case. The less efficient your PSU, the more heat buildup you'll have under load. I chose the Seasonic X-760 – which, when bench tested, indeed delivered the promised 90% efficiency – but any high quality 80 Plus Gold model will generally do.

The CPU (and possibly, depending on your tastes, the video card) is the biggest heat generator inside your PC. The better and more efficient the CPU cooler, the quieter your whole system can be. This also affects how much you can overclock. I chose the Thermalright Venomous-X Silent Edition on the basis of it being the current top dog for efficiency, and because it had a simple mounting system. Large coolers can be a real bear to install. And did I mention it comes with an especially quiet fan out of the box, too?

Once I had all the parts in hand, it was a simple matter of building it up, as documented in my previous post series. I adore this Corsair case; it is an absolute joy to work in. Everything in it is cleverly designed, from the rear cable routing area with rubber grommets all over the place for easily passing cables back and forth, to the tool-less 2.5" and 3.5" bays, to the super easily removable side panels. It's like they read a giant list of all my prior complaints with every PC case I've ever used and fixed every. single. last. one of them.

The end result is what you see here:

New-sandy-bridge-build-internal

There are some significant tweaks visible in the above picture that I do recommend:

  1. Use tin snips to remove the rear exhaust grill. We don't need it back there, and the exhaust airflow is critical. Fan grills affect low-speed fan airflow more than you'd think:
    Wire grills also have an effect: ~20%. This was checked with an anemometer on several different fans of 80, 92 and 120mm size, at full and lower speeds. The airflow reduction went as high as 24% but it was never below 19%. At 12V, the reduction in airflow with most fans will be relatively harmless, though there is an increase in turbulence noise (audible to me). But at the low airflow rates SPCR members run fans, I think the airflow reduction is significant.
  2. Install a 140mm rear exhaust fan. The Noctua NF-P14 is expensive at $25 but is cleverly designed to give you 140mm of super-quiet fan in the space a 120mm fan would normally take. It just barely fits in the rear exhaust fan slot with a little nudging. But it does fit; it's the beige fan in the above picture. It also comes with its own speed reducers and accessories.

  3. Use fan speed reducers on all the fans. The case has two 200mm fans, and the 140mm fan we're adding. I couldn't get the Asus motherboard's "QFan" fan control system to work, as it seems to require 4-pin fans, and all the ones I had (including the ones that came with the case) are 3-pin. While I do prefer dynamic, temperature based control when I can get it, the next best thing is to use hardware to slow down the fans. I like the Zalman-ZM-RC56 resistor connector as the simplest solution, but it's getting hard to find for some reason. The Zalman Fan Mate 2 will also work, and allows you to individually adjust the speed of each fan. The case also has a built in fan controller – that's the knob you see on the front top – but I found it too limited in range for my purposes.

  4. Add acoustic foam to taste. Between inexpensive eggcrate foam and thin, adhesive backed open-cell foam, you can easily reduce that last 10-20% of fan noise to a very pleasant white noise. It works well in the areas pictured, and also on the interior of the side panel "facing" the fans. See item 6 in my Building a Quiet PC post for details.

And then, of course, the overclockening. What kind of geek would I be if I didn't attempt to turn this baby up to 11? This is another area where Sandy Bridge is a revelation: so long as you buy one of the blessed "K" series processors, overclocking is as simple as setting the multiplier to the desired value. It is ridiculously simple. And my results, for once, were immediately as good as the ones everyone else was crowing about: 4.4 GHz totally stable!

Sandy-bridge-overclock

(beware: there is one nasty little issue with the Asus motherboard's auto-overclock feature. The PLL Overvoltage setting, which auto-overclock "helpfully" enables, completely bollixes up resuming from sleep. Just turn it off, and all is well. I don't even want to tell you how long it took me to figure that one out.)

The total package with a nice SSD delivers a near-perfect Windows Experience score:

Sandy-bridge-windows-experience-score

I won't lie to you. This is not a compact build. It's big! Those roomy side areas come at a cost, and that makes it a very wide case. But that's to be expected for a desktop powerhouse machine. And since my last case lasted me from 2007-2011, I'll happily accept a little bulk for something that's easy to work on and upgrade over time.

New-sandy-bridge-build-external

It's a fantastic new reboot of my system, and I didn't expect to be this excited about the final result. This is not merely an incremental improvement over what I had, it's much quieter, easier to work on, and when overclocked to 4.4 GHz, noticeably faster too. (I do slightly mourn the loss of 8 GB of RAM, but I'll survive.)

In this build, I already had hard drives, DVD drive, a sound card, and so forth … but for completeness' sake I'll list everything here if you want to mirror this setup. Realize that some of this comes down to personal taste, so I'm just listing what I recommend. Feel free to change anything out, and bear in mind that Sandy Bridge has decent default onboard video as well.

Remember, if you can put together a LEGO kit, you can build this totally sweet PC for yourself, too. Good luck and happy building!

Source: http://www.codinghorror.com/blog/2011/07/building-a-pc-part-vii-rebooting.html

SEAGATE TECHNOLOGY SCIENTIFIC GAMES SANDISK

Eduasync part 17: unit testing

In the last post I showed a method to implement "majority voting" for tasks, allowing a result to become available as soon as possible. At the end, I mentioned that I was reasonably confident that it worked because of the unit tests... but I didn't show the tests themselves. I felt they deserved their own post, as there's a bigger point here: it's possible to unit test async code. At least sometimes.

Testing code involving asynchrony is generally a pain. Introducing the exact order of events that you want is awkward, as is managing the threading within tests. With a few benefits with async methods:

  • We know that the async method itself will only execute in a single thread at a time
  • We can control the thread in which the async method will execute, if it doesn't configure its awaits explicitly
  • Assuming the async method returns Task or Task<T>, we can check whether or not it's finished
  • Between Task<T> and TaskCompletionSource<T>, we have a way of injecting tasks that we understand

Now in our sample method we have the benefit of passing in the tasks that will be awaited - but assuming you're using some reasonably testable API to fetch any awaitables within your async method, you should be okay. (Admittedly in the current .NET framework that excludes rather a lot of classes... but the synchronous versions of those calls are also generally hard to test too.)

The plan

For our majority tests, we want to be able to see what happens in various scenarios, with tasks completing at different times and in different ways. Looking at the test cases I've implemented I have the following tests:

  • NullSequenceOfTasks
  • EmptySequenceOfTasks
  • NullReferencesWithinSequence
  • SimpleSuccess
  • InputOrderIsIrrelevant
  • MajorityWithSomeDisagreement
  • MajorityWithFailureTask
  • EarlyFailure
  • NoMajority

I'm not going to claim this is a comprehensive set of possible tests - it's a proof of concept more than anything else. Let's take one test as an example: MajorityWithFailureTask. The aim of this is to pass three tasks (of type Task<string>) into the method. One will give a result of "x", the second will fail with an exception, and the third will also give a result of "x". The events will occur in that order, and only when all three results are in should the returned task complete, at which point it will also have a success result of "x".

So, the tricky bit (compared with normal testing) is introducing the timing. We want to make it appear as if tasks are completing in a particular order, at predetermined times, so we can check the state of the result between events.

Introducing the TimeMachine class

Okay, so it's a silly name. But the basic idea is to have something to control the logical flow of time through our test. We're going to ask the TimeMachine to provide us with tasks which will act in a particular way at a given time, and then when we've started our async method we can then ask it to move time forward, letting the tasks complete as they go. It's probably best to look at the code for MajorityWithFailureTask first, and then see what the implementation of TimeMachine looks like. Here's the test:

[Test]
public void MajorityWithFailureTask()
{
    var timeMachine = new TimeMachine();
    // Second task gives a different result
    var task1 = timeMachine.AddSuccessTask(1, "x");
    var task2 = timeMachine.AddFaultingTask<string>(2, new Exception("Bang!"));
    var task3 = timeMachine.AddSuccessTask(3, "x");

    var resultTask = MoreTaskEx.WhenMajority(task1, task2, task3);
    Assert.IsFalse(resultTask.IsCompleted);

    // Only one result so far - no consensus
    timeMachine.AdvanceTo(1);
    Assert.IsFalse(resultTask.IsCompleted);

    // Second result is a failure
    timeMachine.AdvanceTo(2);
    Assert.IsFalse(resultTask.IsCompleted);

    // Third result gives majority verdict
    timeMachine.AdvanceTo(3);
    Assert.AreEqual(TaskStatus.RanToCompletion, resultTask.Status);
    Assert.AreEqual("x", resultTask.Result);
}

As you can see, there are two types of method:

  • AddSuccessTask / AddFaultingTask / AddCancelTask (not used here) - these all take the time at which they're going to complete as their first parameter, and the method name describes the state they'll reach on completion. The methods return the task created by the time machine, ready to pass into the production code we're testing.
  • AdvanceTo / AdvanceBy (not used here) - make the time machine "advance time", completing pre-programmed tasks as it goes. When those tasks complete, any continuations attached to them also execute, which is how the whole thing hangs together.

Now forcing tasks to complete is actually pretty simple, if you build them out of TaskCompletionSource<T> to start with. So all we need to do is keep our tasks in "time" order (which I achieve with SortedList), and then when we're asked to advance time we move through the list and take the appropriate action for all the tasks which weren't completed before, but are now. I represent the "appropriate action" as a simple Action, which is built with a lambda expression from each of the Add methods. It's really simple:

public class TimeMachine
{
    private int currentTime = 0;
    private readonly SortedList<int, Action> actions = new SortedList<int, Action>();

    public int CurrentTime { get { return currentTime; } }

    public void AdvanceBy(int time)
    {
        AdvanceTo(currentTime + time);
    }

    public void AdvanceTo(int time)
    {
        // Okay, not terribly efficient, but it's simple.
        foreach (var entry in actions)
        {
            if (entry.Key > currentTime && entry.Key <= time)
            {
                entry.Value();
            }
        }
        currentTime = time;
    }

    public Task<T> AddSuccessTask<T>(int time, T result)
    {
        TaskCompletionSource<T> tcs = new TaskCompletionSource<T>();
        actions[time] = () => tcs.SetResult(result);
        return tcs.Task;
    }

    public Task<T> AddCancelTask<T>(int time)
    {
        TaskCompletionSource<T> tcs = new TaskCompletionSource<T>();
        actions[time] = () => tcs.SetCanceled();
        return tcs.Task;
    }

    public Task<T> AddFaultingTask<T>(int time, Exception e)
    {
        TaskCompletionSource<T> tcs = new TaskCompletionSource<T>();
        actions[time] = () => tcs.SetException(e);
        return tcs.Task;
    }
}

Okay, that's a fair amount of code for a blog posts (and yes, it could do with some doc comments etc!) but considering that it makes life testable, it's pretty simple.

So, is that it?

It works on my machine... with my test runner... in simple cases...

When I first ran the tests using TimeMachine, they worked almost immediately. This didn't surprise me nearly as much as it should have done. You see, when the tests execute, they use async/await in the normal way - which means the continuations are scheduled on "the current task scheduler". I have no idea what the current task scheduler is in unit tests. Or rather, it feels like something which is implementation specific. It could easily have worked when running the tests from ReSharper, but not from NCrunch, or not from the command line NUnit test runner.

As it happens, I believe all of these run tests on thread pool threads with no task scheduler allocated, which means that the continuation is attached to the task to complete "in-line" - so when the TimeMachine sets the result on a TaskCompletionSource, the continuations execute before that call returns. That means everything happens on one thread, with no ambiguity or flakiness - yay!

However, there are two problems:

  • The words "I believe" aren't exactly confidence-inspiring when it comes to testing that your software works correctly.
  • Our majority voting code only ever sees one completed task at a time - we're not testing the situation where several tasks complete so quickly together that the continuation doesn't get chance to run before they've all finished.

Both of these are solvable with a custom TaskScheduler or SynchronizationContext. Without diving into the docs, I'm not sure yet which I'll need, but the aim will be:

  • Make TimeMachine implement IDisposable
  • In the constructor, set the current SynchronizationContext (or TaskScheduler) to a custom one having remembered what the previous one was
  • On disposal, reset the context
  • Make the custom scheduler keep a queue of jobs, such that when we're asked to advance to time T, we complete all the appropriate tasks but don't execute any continuations, then we execute all the pending continuations.

I don't yet know how hard it will be, but hopefully the Parallel Extensions Samples will help me.

Conclusion

I'm not going to claim this is "the" way of unit testing asynchronous methods. It's clearly a proof-of-concept implementation of what can only be called a "test framework" in the loosest possible sense. However, I hope it gives an example of a path we might take. I'm looking forward to seeing what others come up with, along with rather more polished implementations.

Next time, I'm going to shamelessly steal an idea that a reader mailed me (with permission, of course). It's insanely cool, simple and yet slightly brain-bending, and I suspect will handy in many situations. Love it.

Source: http://feedproxy.google.com/~r/JonSkeetCodingBlog/~3/DnRbqgbMyKE/eduasync-part-17-unit-testing.aspx

L1 IDENTITY SOLUTIONS KINGSTON TECHNOLOGY COMPANY KEY

Friday, December 2, 2011

Gimme Bar+TwitterFeed+PHP = One-click Syndication - blog.phpdeveloper.org » PHP

I recently set up a new Twitter account that shares links to some of the smaller stories I come across in my news reading for PHPDeveloper.org called @phpquickfix. I recently had started playing with Gimme Bar more and wondered how easy it?d be to set it up as a backend repository for some links. Thanks to some hints from other blog posts, it was super easy to set up a ?one click syndication? system that combines Gimme Bar, Twitterfeed and a little bit of PHP.

Here?s how it?s set up:

  • I have an account for the PHP Quick Fix over on Gimme Bar here. I use their Chrome extension (and sometimes the bookmarklet) to grab the pages that I want to add.
  • There?s a little PHP script I put together that does a few things ? first, if the cached json from the Gimme Bar feed is out of date, it grabs it and wgets the latest from their API. Then it parses this json and outputs it as a simple RSS feed. You can see the result here.
  • Finally, we add Twitterfeed into the mix ? it pulls from the RSS feed and posts it to Twitter automatically.

The end result is a system where I can click ?Gimme the Page? to my public collection and let the services do the rest. There?s no automation in the link selection ? it?s all chosen with my own ?human aggregation system?. I think it?s a pretty simple solution to the problem ? plus it has the added benefit of making a good collection of hand-picked PHP resources for anyone to pull from.

UPDATE: You can also directly access the PHP Quick Fix posts over on it?s feed: http://phpquickfix.me/feed.

Source: http://blog.phpdeveloper.org/?p=413

SYNNEX SYMANTEC SYKES ENTERPRISES INORATED

Nobody's Going to Help You, and That's Awesome

I'm not into self-help. I don't buy self-help books, I don't read productivity blogs, and I certainly don't subscribe to self-proclaimed self-help guru newsletters. Reading someone else's advice on the rather generic concept of helping yourself always struck me as a particularly misguided idea.

Apparently I'm not the only person to reach this conclusion, either.

I spent two years reading all the self-help books I could find. As of a year ago, I had read 340 self-help books. Because I?m insane.

My conclusion from all that reading?

95% of self-help books are complete bullshit.

To be clear, I am all for self-improvement. Reading books, blogs, and newsletters by people who have accomplished great things is a fine way to research your own path in life. But these people, however famous and important they may be, are not going to help you.

Unfortunately that's not the answer he wanted. To him, my answer [that nobody was going to help him become successful] was really discouraging. To me, if I was receiving that answer from someone else, it would be really encouraging.

I like being reminded that nobody's going to help me - that it's all up to me. It puts my focus back on the things I can control - not waiting for outside circumstances.

Take it from The Ultimate Productivity Blog:

Ultimate-productivity-blog

Reading self-help advice from other people, however well-intentioned, is no substitute for getting your own damn work done. The sooner you come to terms with this, the better off you'll be.

Get out there and do stuff because you fundamentally enjoy it and because it makes you better. As a writer, as an analyst, as a techie, whatever. Learn to love practicing the fundamentals and do it better each time. Over time, quality does lead to success, but you have to be patient. Really patient. Turns out, "overnight" success takes years. Maybe even decades. This is not a sprint, it's a marathon. Plan accordingly.

For example, I don't care if anyone reads what I write here. I'm writing to satisfy myself first and foremost. If others read it and benefit from it, fantastic -- that's a welcome side effect. If I worry about who is reading, why they're reading, or if anyone is even reading at all, I'd be too paralyzed to write! That'd be the least productive outcome of all.

That's not to say that some introspection about the nature of your work isn't useful. It is. Even the weary self-help student I quoted above concluded that 5% of self-help advice surprisingly wasn't bullshit. The one book he recommended without hesitation? 59 Seconds: Think a Little, Change a Lot.

59-seconds-book-cover

Despite my deep reservations about the genre, I ordered this book based on his recommendation and a number of credible references to it I noticed on the Skeptic Stack Exchange.

Why does this self-help book work when so many others fail? In a word, science! The author goes out of his way to find actual published scientific research documenting specific ways we can make small changes in our behavior to produce better outcomes for ourselves and those around us. It's powerful stuff, and the book is full of great, research backed insights like this one:

A group of participants were asked to select a negative experience. One group of participants were then asked to have a long chat with a supportive experimenter about the event, while a second group were invited to chat about a far more mundane topic - a typical day.

Participants who had spent time talking about their traumatic event thought the chat had been helpful. However, the various questionnaires told a very different story. In reality the chat had no significant impact at all. They might just as well have been chatting about a typical day.

In several studies, participants who have experienced a traumatic event have been encouraged to spend just a few minutes each day writing in a diary-type account of their deepest thoughts and feelings about it. For example, in one study participants who had just been made redundant were asked to reflect upon their deepest thoughts and feelings about their job loss, including how it had affected both their personal and professional lives. Although these types of exercises were both speedy and simple, the results revealed a remarkable boost in their psychological and physical well-being, including a reduction in health problems and an increase in self-esteem and happiness.

The results left psychologists with something of a mystery. Why would talking about a traumatic experience have almost no effect but writing about it yield such significant benefits? From a psychological perspective, talking and writing are very different. Talking can often be somewhat unstructured, disorganized, even chaotic. In contrast, writing encourages the creation of a story line and structure that help people make sense of what has happened and work towards a solution. In short, talking can add to a sense of confusion, but writing provides a more systematic, solution-based approach.

Therefore, the real world change you would make based on this advice – the proverbial 59 seconds on the book jacket – is to avoid talking through traumatic experiences in favor of writing about them. Not because some self-help guru said so, but because the published research data tells us that talking doesn't work and writing does. Not exactly intuitive, since talking through our problems with a friend always feels like the right thing to do, but I have certainly documented many times over the value of writing through a problem.

59 Seconds is so good, in fact, it has rekindled my hopes that our new Stack Exchange Productivity Q&A can work. I'd love for our productivity site to be founded on a scientific basis, and not the blind cult of personality I've come to expect from the self-help industry.

Remember, nobody's going to help you … except science, and if you're willing to put in the required elbow grease each and every day – yourself.

Source: http://www.codinghorror.com/blog/2011/07/nobodys-going-to-help-you-and-thats-awesome.html

TRIDENT MICROSYSTEMS TRANSACTION SYSTEMS ARCHITECTS TOTAL SYSTEM SERVICES

JavaScript Constructors Were a Mistake and Should Be Removed

Source: http://my2iu.blogspot.com/2011/04/javascript-constructors-were-mistake.html

RACKABLE SYSTEMS QUEST SOFTWARE QUANTUM

Optional argument corner cases, part three

(This is part three of a series on the corner cases of optional arguments in C# 4; part two is here. Part four is here.)

A lot of people seem to think that this:

void M(string x, bool y = false) { ... whatever ... }

is actually a syntactic sugar for the way you used to have to write this in C#, which is:

void M(string x) { M(x, false); }
void M(string x, bool y) { ... whatever ... }

But it is not. The syntactic sugar here is not on the declaration side, but rather on the call side. There is only one method; when you make a call that omits optional arguments, the compiler simply inserts the arguments at the call site. That is:

M("hello");

is rewritten as

M("hello", false);

It would actually be pretty weird if we did it on the declaration side, because what would you do about this?

void N(bool a1 = false, bool a2 = false) { ... whatever ... }

Clearly we can't generate

void N() { N(false, false); }
void N(bool a1) { N(a1, false); }
void N(bool a2) { N(false, a2); }
void N(bool a1, bool a2) { ... whatever ... }

because now we have two methods with the same signature. But why would we need to generate the "a2" method in the first place? Because we added named arguments as well as optional arguments. Someone could call:

N(a2: true);

Clearly we have to rewrite the caller side, not the called side.

An argument with a default value does not change the signature at all, so anything that relies upon signature matching still needs to have an exact match. That is, even though you can say:

M("hello");

and you can say

Action<string> action = (string s)=>{M(s);};

You cannot say

Action<string> action = M;

Because M does not have a signature match with that delegate type; the delegate is expecting a method that takes a string, but you're giving it a method that takes a string and a bool. Where is the code generated that fills in the bool? There is no call site here, and the default value has to be filled in at the call site.

Similarly, you can't do something like this:

class B
{
  public virtual void M(string x, bool y = false) {}
}
class D : B
{
  public override void M(string x) {}
}

Or this:

class D : B
{
  public override void M(string x, bool y = false, int z = 123) {}
}

The signatures have to match to do an override, and default values for missing arguments are not part of the signature.

Next time: more consequences of call-site rewriting.

(This is part three of a series on the corner cases of optional arguments in C# 4; part two is here. Part four is here.)

Source: http://blogs.msdn.com/b/ericlippert/archive/2011/05/16/optional-argument-corner-cases-part-three.aspx

LAND SOFTWARE LAM RESEARCH L1 IDENTITY SOLUTIONS

Breaking changes and named arguments

Before I get into the subject of today's post, thanks so much to all of you who have given us great feedback on the Roslyn CTP. Please keep it coming. I'm definitely going to do some articles on Roslyn in the future; the past few weeks I have been too busy actually implementing it to write much about it.


We introduced "named and optional arguments" to C# 4.0; that's the feature whereby you can omit some optional arguments from a method call, and specify some of them by name. This makes the code more self-documenting; it also makes it much easier to deal with methods in legacy object models that have lots and lots of parameters but only a few are relevant. The most common commentary I've seen about the "named" side of that feature is people noting that this introduces a new kind of breaking change. The commentary usually goes something like:

Suppose you are making a library for consumption by others. Of course if you change details of the public surface area of the library, you can break consumers of the library. For example, if you add a new method to a class then you might make an existing program that compiled just fine now turn into an error-producing program because a call to the old method is now ambiguous with a call to the new method. In the past, changing only the name of a formal parameter was not a "breaking change", because consumers always passed arguments positionally. Recompilation would not produce different results. In a world with named arguments though, it is now the case that changing the name of a formal parameter can cause working code to break.

Though that commentary is certainly well-intentioned and informative, it is not quite accurate. The implication is that this breaking change is something new, when in fact it has always been the case that a library provider could break consumers by changing only the name of a formal parameter. Visual Basic has always supported calling methods with named parameters. In the past, changing the name of a formal parameter was a breaking change for any consumers using Visual Basic, and that's potentially a lot of people. Now it becomes a potential breaking change for even more users. Adding a new feature to C# doesn't change the fact that the risk was always there!

Library providers should already have been cautious about changing the names of formal parameters, and they should continue to be cautious now.

 

Source: http://blogs.msdn.com/b/ericlippert/archive/2011/11/07/breaking-changes-and-named-arguments.aspx

NETWORK APPLIANCE NETGEAR NCR

Thursday, December 1, 2011

Async articles

I am pleased to announce that MSDN Magazine is doing a special issue this month on the new "async-await" feature that we are working on for the next versions of C# and Visual Basic. If this subject interests you, see my introductory article for beginners, Mads Torgersen's article on how it works behind the scenes and Stephen Toub's expert-level article on async performance. And of course, for a much longer introduction to the topic, see my long series from earlier this year. If you want to try it out yourself, download the CTP build from the async CTP main page.

Please do keep the great feedback coming! If you have comments, questions or constructive feedback on any aspect of the new feature, please post it to the async forum. Thanks!

 

Source: http://blogs.msdn.com/b/ericlippert/archive/2011/10/03/async-articles.aspx

OSI SYSTEMS ORACLE OPENWAVE SYSTEMS

Why do we need www?

Source: http://yacoding.blogspot.com/2007/10/why-do-we-need-www.html

THQ TEXAS INSTRUMENTS TERADATA

Optional argument corner cases, part three

(This is part three of a series on the corner cases of optional arguments in C# 4; part two is here. Part four is here.)

A lot of people seem to think that this:

void M(string x, bool y = false) { ... whatever ... }

is actually a syntactic sugar for the way you used to have to write this in C#, which is:

void M(string x) { M(x, false); }
void M(string x, bool y) { ... whatever ... }

But it is not. The syntactic sugar here is not on the declaration side, but rather on the call side. There is only one method; when you make a call that omits optional arguments, the compiler simply inserts the arguments at the call site. That is:

M("hello");

is rewritten as

M("hello", false);

It would actually be pretty weird if we did it on the declaration side, because what would you do about this?

void N(bool a1 = false, bool a2 = false) { ... whatever ... }

Clearly we can't generate

void N() { N(false, false); }
void N(bool a1) { N(a1, false); }
void N(bool a2) { N(false, a2); }
void N(bool a1, bool a2) { ... whatever ... }

because now we have two methods with the same signature. But why would we need to generate the "a2" method in the first place? Because we added named arguments as well as optional arguments. Someone could call:

N(a2: true);

Clearly we have to rewrite the caller side, not the called side.

An argument with a default value does not change the signature at all, so anything that relies upon signature matching still needs to have an exact match. That is, even though you can say:

M("hello");

and you can say

Action<string> action = (string s)=>{M(s);};

You cannot say

Action<string> action = M;

Because M does not have a signature match with that delegate type; the delegate is expecting a method that takes a string, but you're giving it a method that takes a string and a bool. Where is the code generated that fills in the bool? There is no call site here, and the default value has to be filled in at the call site.

Similarly, you can't do something like this:

class B
{
  public virtual void M(string x, bool y = false) {}
}
class D : B
{
  public override void M(string x) {}
}

Or this:

class D : B
{
  public override void M(string x, bool y = false, int z = 123) {}
}

The signatures have to match to do an override, and default values for missing arguments are not part of the signature.

Next time: more consequences of call-site rewriting.

(This is part three of a series on the corner cases of optional arguments in C# 4; part two is here. Part four is here.)

Source: http://blogs.msdn.com/b/ericlippert/archive/2011/05/16/optional-argument-corner-cases-part-three.aspx

WESTERN DIGITAL VOLT INFORMATION SCIENCES VISHAY INTERTECHNOLOGY

Arabic Support in Java

Source: http://my2iu.blogspot.com/2011/09/arabic-support-in-java.html

NCR NATIONAL SEMICONDUCTOR NATIONAL INSTRUMENTS

Regular Expressions in C# ? The Basics

One of the most common coding tasks is to take an input, munch it around and turn it into something different altogether. Are you looking for FedEx numbers in a text file? Do you want to replace “love” with “hate” in your source files? Is a string a valid e-mail address? Problems like these can [...]

This is a post from Martijn's C# Coding Blog.

Source: http://www.dijksterhuis.org/regular-expressions-in-csharp-the-basics/

WESTERN DIGITAL VOLT INFORMATION SCIENCES VISHAY INTERTECHNOLOGY