|
When monies short!
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
Mike Hankey wrote: not having internet on my home PC
How is this even humanly possible? 
|
|
|
|
|
Mike Hankey wrote: months of not having internet
I'm jealous.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Mike Hankey wrote: After months of not having internet on my home PC I'm finally back online.
How on Earth did you survive? 
Was it a revelation like this[^]? 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
|
Couldn't you hack into someone's wireless? There's always someone around who still uses WEP.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Where I live is so far out they have to pump sunshine in.
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
Mike Hankey wrote: Where I live is so far out they have to pump sunshine in.
Did you move to rural Canada?
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
I have a task that is maybe three calls deep from the MVVM Login command to the Web API call for a token. The API had an erroneous connection string, to an older version of the database*, and the UserManager.CreateUser method was failing in the Register action. It took about fifteen minutes, and a hard break-point, e.g. Debug.Fail(), to find the error.
The stack trace was most confounding, and it mentioned the Account controller and the error once that I could see in an 86 line long stack track, most of which were exceptions on a MoveNext() method on a slew of async tasks.
It is clear that I have some learning to do regarding configuring the innermost task, the long running one that is to be awaited, and that learning will begin tomorrow morning at 04h30, my normal starting time. Time to consult the venerable Mr. Skeet's seminal tome on C# 5.
* It's damned annoying how EF drops a default connection string, like a turd, into your config file, that points to the new fangled LocalDb. Then you forget to set one up, your first migration creates the DB there, then when you can't connect to where you expect it, you fix the connection string, and re-run the migration in the right database. Then, when you have done a few more migrations, and add e.g. a test project, it is once again pointing to the out-of-date LocalDb version.
|
|
|
|
|
Well, if you would use a flat file and single thread the thing, then you wouldn't have these problems! 
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
Now you've given me an idea. A flat file provider for EF, even with FKs, and a migrations module for that provider.
|
|
|
|
|
Glad I could help? 
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
async/await is, IMO, something to be avoided except for very specific, simple, quick running, one-level deep, things. Besides the fact that you have to be careful of whether you have long running tasks, which the underlying task management doesn't like (I think this is still accurate), nested async/awaits are a brain-f*** -- ok, when the continuation returns here, then it returns here, then it returns here...but what happens when an exception is thrown...
Frankly, In most cases, I much prefer good 'ol System.Threading.Thread.
Marc
|
|
|
|
|
I wouldn't dream of nesting awaited Tasks, except maybe with a year's analysis and planning of continuations, but in this case, now I've done things properly (found an excellent tutorial), a task takes a lot off my hands, and it is only used to keep the UI responsive and able to cancel, the quasi-long-running API call. It's my own API, and dedicated to this one client.
If I get brave enough, I might stretch it and venture into multiple parallel continuations, but all first level only; start and finish. The TPL, even without the magic of await, just just all the System.Threading plumbing for me.
|
|
|
|
|
Marc Clifton wrote: ok, when the continuation returns here, then it returns here, then it returns here...but what happens when an exception is thrown...
async and await make it easier to reason about that sort of code. For the most part, it's basically the same as synchronous code, except it doesn't block the thread waiting for external calls to complete.
A simple example:
Synchronous code:
Ping ping = new Ping();
try
{
PingReply reply = ping.Send(address);
}
catch (PingException)
{
}
EAP code:
Ping ping = new Ping();
PingCompletedEventHandler handler = null;
handler = (sender, e) =>
{
ping.PingCompleted -= handler;
if (e.Error != null)
{
PingException ex = e.Error as PingException;
if (ex == null) throw new TargeInvocationException("Error", e.Error);
}
else
{
PingReply reply = e.Reply;
}
};
ping.PingCompleted += handler;
ping.SendAsync(address);
Continuation passing code:
Ping ping = new Ping();
Task<PingReply> pingTask = ping.SendPingAsync();
Task resultTask = pingTask.ContinueWith(task =>
{
if (task.IsFauled)
{
AggregateException ex = task.Exception;
ex.Handle(error =>
{
PingException pingEx = error as PingException;
if (pingEx == null) return false;
return true;
});
}
else
{
PingReply reply = task.Result;
}
});
Async code:
Ping ping = new Ping();
try
{
PingReply reply = await ping.SendPingAsync(address);
}
catch (PingException)
{
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Wow, wish I could give you multiple 5's for such a complete response!
Yes, async/await does definitely make life easier, until it doesn't. 
Marc
|
|
|
|
|
A damned good, ideally detailed example!
You should make an article of this.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Programming question, in the lounge? tut tut...
|
|
|
|
|
I see no question in my post, and it is even marked as a rant.
|
|
|
|
|
Brady Kelly wrote: Mr. Skeet
I heard all threads wait for him to finish.
|
|
|
|
|
|
ever tried doing recursion using async methods, like loading a data tree in which each node has only asyc loading methods available (remember RT version of Windows 8.x in the "old days"? dunno how the API is changed now) . The async and await syntax makes it much, much simpler ...
|
|
|
|
|
Wow, no, never got anything that complex. I would imagine with await you'd need a separate AppDomain for the unknown number of threads, and then just kill it off afterwards, rather than bloat and complicate your code tracking them.
|
|
|
|
|
Well, what I meant here is that it's not really that complicated using async/await  , compared to other methods. And it can be used consistently in any layers of call stacks ...
Imagine in a system that only asynchronous system calls are available (like in the RT subsystem of Windows and in part of nodejs), it would be very hard to build any backend, midware or API systems complex enough for real world applications, which most likely have many layers of abstraction on top, base on callbacks or event handlers. It's sometimes been referred to as callback hell, the origin of many subtle bugs ...
However async/await support (kind of coroutine) of a language makes it possible to make the code almost like the synchrounous one so that a programer can apply the sequential execution reasonning about the code and does not has to worry about the underlying async mechanism, which are managed by thread pools or even are not thread based (event driven systems, like nodejs). We had built quite complex systems in nodejs (using promises, similar to async/await) and Windows RT (before) using async/await.
|
|
|
|
|
|
Yeah. I miss his answers (@SAKryukov) too.
Where did he go?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif)
