Support await keyword

[georgiosd]

Any chance to support awaiting for tasks?

[georgiosd]

Could anyone explain what needs to be done to support this? I'd be willing to give it a go

[lukebuehler]

Hey sorry about the delay.

In the current release this works:

Task.Run(async () => {
 await Task.Delay(1000);
 Console.WriteLine("Delayed");
});

We've switched in the latest dev branch to the Roslyn scripting engine. Which solve quite a few other problems, BUT it break the async capability.

See: http://stackoverflow.com/questions/15312892/could-roslyn-compile-await-keyword

Which version are you using?

[georgiosd]

Hrmpf, I'd swear I had problems doing await Task.Run(() => {}); before but I must have been tired or something. I'm on 30750 - any advantages to compiling from source?

One a different note - are there points for extensibility? e.g. ways to add windows or interact with the shell?

Also, how does one deal with referencing assemblies that may need recompilation? I mean, I wanted to use CShell for testing but every time I need to modify the source, I need to close CShell so that VStudio can overwrite the DLL - is there any solution to this?

[georgiosd]

Ah yes - await is accepted as a keyword but doesn't seem to be awaited:

 > await Task.Run(async () => { await Task.Delay(5000); return 5; });
System.Threading.Tasks.Task`1[System.Threading.Tasks.VoidTaskResult] 

[georgiosd]

Strangely enough, the await for the delay is respected but the top level one is not.

I guess no way to support await in dev branch until Roslyn is released...

[georgiosd]

See scriptcs/scriptcs#570

[georgiosd]

Ok, so - I was able to make this work by patching the ScriptCs MonoScriptEngine as shown in the patch in the link above and then replacing the RoslynScriptEngine with the MonoScriptEngine in CShell.

I guess this brings up the desire to allow the user to decide where to pick the IScriptEngine from since ScriptCs supports several. Do you know how you'd like that to be configurable? Through the UI, config file or command args? Perhaps I can send a PR.

[lukebuehler]

Yep, over the last few days I've come to the conclusion that we need to support both scripting engines in CShell. At first I decided to go Roslyn all the way... but as we see in this thread this has it's own problems.

So yes, I agree we should support both engines. I think it will be a startup argument. We do NOT support ScriptCS modules and have to implement some kind of switch ourselves.

[georgiosd]

Well hopefully the roslyn release will be soon and it should support await...

Sent from a device with a small keyboard

On 12 Sep 2014, at 21:33, "Lukas Buhler" [email protected] wrote:

Yep, over the last few days I've come to the conclusion that we need to support both scripting engines in CShell. At first I decided to go Roslyn all the way... but as we see in this thread this has it's own problems.

So yes, I agree we should support both engines. I think it will be a startup argument. We do NOT support ScriptCS modules and have to implement some kind of switch ourselves.

—
Reply to this email directly or view it on GitHub.

[IBIT-ZEE]

I have studied a bit Roslyn and in my opinion Micro$oft could provide the same
services in .net 4.0...
maybe they could call it .net 4.1.. or ??? whatever!!!

but they are too eager to promote the 4.5 thing to force people to abandon NT5x
(xp/2003 mainly)

The same problem occours with SQL Server 2014... needs net 4.5.. so no updates
for 2003 server...
thank god there are mySQL and other apps not depending on net 4.5

Couriously,,, even the new M$ Office works on XP... or M$ will loose a lot of
$$$...

I completely diagree on this way... of evolution...

;-)

---

From: Lukas Buhler [mailto:[email protected]]
Sent: sexta-feira, 12 de Setembro de 2014 19:34
To: lukebuehler/CShell
Subject: Re: [CShell] Support await keyword (#48)

Yep, over the last few days I've come to the conclusion that we need to support
both scripting engines in CShell. At first I decided to go Roslyn all the way...
but as we see in this thread this has it's own problems.

So yes, I agree we should support both engines. I think it will be a startup
argument. We do NOT support ScriptCS modules and have to implement some kind of
switch ourselves.

Reply to this email directly or view
#48 (comment) it on
GitHub.
<https://github.com/notifications/beacon/3254076__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY2
9uIiwiZXhwaXJlcyI6MTcyNjE2NjAzNCwiZGF0YSI6eyJpZCI6Mzc5NTYwNjV9fQ==--7f64a254c9b2
548bec90d88e2f540243ef818af8.gif>

[lukebuehler]

will close since #68 will solve this.