Interactive Design Meeting Notes - 2/25/15

[kuhlenh]

Interactive Meeting Notes - 2/25/2015

We met with scriptcs team this morning.

Next Steps:
Help unblock scriptcs so they can get scriptcs running on the new Roslyn bits

• Filip will tag issues with “Interactive Design” “Interactive-Scripting” “Bug” and title them “[scriptcs] titleOfIssue”
• Filip is being blocked by our evolving compiler APIs and our lack of a NuGet for Roslyn that has scripting APIs in it (we may need to generate a separate NuGet that they can consume and that has the language service features they need for syntax-coloring, etc.). The language services are currently internal so we will need to make this into a NuGet.
• Ask scriptcs for a spec of their package management

We discussed our milestones

• Enable scriptcs to opt-in to using the new Roslyn compiler
• Unify scripting (nuget management, language semantics, directives)
• Integrate their interpreter to execute our scripts
• Figure out the debugging scenarios and experiences

We discussed our vision

Imagine: a script written in scriptcs can be opened and edited in VS and in the Interactive Window. Likewise, a script written in VS can be run in the scriptcs command-line and built in the ScriptCS command-line REPL. It should be a friction-less experience to shift between the environments and the scripting experience itself should be the same.

In this vision, the IntEx team would be responsible for the Interactive Window (IW) experience in-the-box in Visual Studio. This includes the window itself as well as the C# and VB REPL. The IW should be able to load script files created in scriptcs command-line. Script files can be executed using scriptcs in a command-line or in the VS IW. We will use scriptcs's equivalent of csi.exe that can run scripts from the command-line.

The scriptcs team would be responsible for maintaining their command-line REPL and scripting experience.

Together, our teams would have to solve our NuGet handling, scripting semantics, and directives disparities.

What we learned

scriptcs has an extensible model, meaning that all engines are “pluggable.” This would mean we can plug a Visual Basic Engine into their platform as well as our cross-platform engine without too many issues. They are open to this integration with VB the only question is who will maintain this.

We also learned that the value-prop of scriptcs lies primarily in its layered “wrapping,” surfacing convention-based experiences to developers to make loading packages, binaries, dlls easy and letting the developer solely worry about writing code.

Packages.conf file

While the scriptcs team liked our solution (aka Fowler’s shared library API), they already have customers who rely on the packages.conf workflow. They are open to discussing deprecating the packages.conf over time.

Their biggest worry

Is that we will destroy their freedom. We need to show them that Microsoft won’t slow them down or inhibit their success and transparency.

[glennblock]

We're very excited about this collaboration, thanks for reaching out!

[kasajian]

If you remove the variable of what is feasible, and focus solely on end-user experience, the workflow that's ideal is something like this:

I see a .csx file on the disk. I can edit it. Run it from the command line., etc. Just like scriptcs does today. However, in addition to that, I want to be able to pen the .csx file from within Visual Studio and image it behaving as if I just opened a solution. That is, I can do all the things I'm can do with Visual Studio in a console application, including:

1. Easily add NuGet packages.
2. Edit / Debug.
3. Intellisense
4. Resharper
5. Unit testing.
   And to do this as close as possible to be a first-class citizen within Visual Studio.

I took some liberties above -- "what does it mean to open a .csx file a solution? it's not a solution. it's a file". True, but what I mean is, when I open it, everything else falls into place. My "references" are there in the Solution Explorer. I don't have to set up the debugger to execute scriptcs.exe manually, with -debug flag, etc. It does all that for me. Even, somehow, it knows where to go for Unit Tests.

Today, I can simulate some of this, with some manual steps. As follows:

1. I would put most of the logic of the script in separate C# files, in classes, using C# syntax that's compatible with both scriptcs and regular C#.
2. I would have a single .csx file that #loads the other class files. Visual Studio doesn't compile this.
3. I'd have a Visual Studio Class Library project which includes each of the class files, but not the .csx file. The project builds a DLL.
4. For debugging, I point to scriptcs.exe -debug and pass in the .csx file.
5. When the debugger is started, scriptcs.exe is launched and it will load the .csx files and each of the associated class files being loaded #load. In fact, the actual assembly created by Visual Studio (in bin\debug) won't be the one being debugged.
6. I'll need to be able to support command arguments to the script. And from Visual Studio, I should be able to add the arguments to the debugger project settings.
7. The .dll in bin\debug is really only used during unit testing.

I haven't done of this so I really haven't vetted this out. I'm really only posting this to get a discussion going and to get further feedback.
If this approach makes sense, and I use it, I'll write a proper blog on what actually we ended up with.

Ref: https://groups.google.com/forum/#!topic/scriptcs/jl5h9tUQ9XA

[glennblock]

@kasajian we also have this approach which works for debugging in VS: https://github.com/scriptcs/scriptcs/wiki/Debugging-a-script. Have you tried it?

Today it doesn't get full intellisense etc, but it "could". It would also be nice as WebMatrix has to just be able to point to a folder and open it without needing any sln or anything.

[kasajian]

Thank you. I did reference that. Debugging in the way you describe works good. But it isn't just debugging. It's really a hybrid that I'm looking for. I want all the benefits of scriptcs but with the option of not giving up any if the benefits for visual studio.

I'll set it up. I was more curious if anyone else has attempted to share source between scriptcs and visual studio.

Kenneth Kasajian -- Mobile call or text: 949-288-3717, Skype: kkasajian

On Feb 26, 2015, at 4:36 PM, Glenn Block notifications@github.com wrote:

@kasajian we also have this approach which works for debugging: https://github.com/scriptcs/scriptcs/wiki/Debugging-a-script

Today it doesn't get full intellisense etc, but it "could". It would also be nice as WebMatrix has to just be able to point to a folder and open it without needing any sln or anything.

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

[glennblock]

Well you can edit the scripts in VS as well, which is why I mentioned it. I
don't think refactoring will work though.

I am not aware of anyone doing this, but does not mean they are not. The
one challenge with what you are describing though is namespaces. If you
want your scripts to work between both, then you cannot have namespaces in
the classes as those are not supported in script as Roslyn will wrap
everything in an outer submission class.

On Thu, Feb 26, 2015 at 5:16 PM Kenneth Kasajian notifications@github.com
wrote:

Thank you. I did reference that. Debugging in the way you describe works
good. But it isn't just debugging. It's really a hybrid that I'm looking
for. I want all the benefits of scriptcs but with the option of not giving
up any if the benefits for visual studio.

I'll set it up. I was more curious if anyone else has attempted to share
source between scriptcs and visual studio.

Kenneth Kasajian -- Mobile call or text: 949-288-3717, Skype: kkasajian

On Feb 26, 2015, at 4:36 PM, Glenn Block notifications@github.com
wrote:

@kasajian we also have this approach which works for debugging:
https://github.com/scriptcs/scriptcs/wiki/Debugging-a-script

Today it doesn't get full intellisense etc, but it "could". It would
also be nice as WebMatrix has to just be able to point to a folder and open
it without needing any sln or anything.

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

—
Reply to this email directly or view it on GitHub
#907 (comment).

[kasajian]

glenn, thanks. Now that you mention it, I remember reading about that. You're right. Namespaces will need to be avoided.

If anything else comes to mind, let me know.

[Pilchie]

We talked a lot about namespaces in the meeting described by Issue #122. As mentioned in the NOTE under #load, we considered having #load of a .cs file (not a .csx file) switch to using CS semantics, though there were some technical issues with that.

We didn't feel that it was something we needed on day one, but it was definitely attractive for the reasons you mention.

[glennblock]

@Pilchie #load as you are describing to allow reusing standard .cs files from a script does sound useful. I agree it is not needed for day one.

@kasajian are you asking for full IDE support for scripts? meaning intellisense, refactoring etc for csx files?

[Pilchie]

@glennblock well I definitely want full IDE support for scripts. Why wouldn't you?

[kasajian]

Kevin, thanks for the response.

"Asking for" isn't how I would put it. I was describing what I believed
to be the utopian view of what I would want. I am not actually making a
feature request. What I'm asking is, for someone who wants to have the
luxury of C# script with no build-step, like with scriptcs, but have all of
the advantages of Visual Studio, what process would they follow? I believe
one can do that simply by arranging their source and solutions a certain
way. So without changes to either scriptcs or Visual Studio, it could be
done. I was simply wanting to know if anyone has done that yet so that I
can build-up on that. Sounds like may be not, so I'll get the ball
rolling.

Thanks again.

On Thu, Feb 26, 2015 at 7:46 PM, Glenn Block notifications@github.com
wrote:

@Pilchie https://github.com/Pilchie #load as you are describing to
allow reusing standard .cs files from a script does sound useful. I agree
it is not needed for day one.

@kasajian https://github.com/kasajian are you asking for full IDE
support for scripts? meaning intellisense, refactoring etc for csx files?

—
Reply to this email directly or view it on GitHub
#907 (comment).

[madstt]

👍

[glennblock]

@Pilchie I want that without a doubt! :-)

[filipw]

@Pilchie on the editor front and overall authoring experience, we are also involved in the omnisharp-roslyn effort to introduce scriptcs support there - as a 3rd project system (MSBuild, ASP.NET 5, scriptcs)

[RichiCoder1]

I'm also very interested in this as I use cake-build/cake, and I know they'd benefit from a powerful IDE experience for scripts, as well as an exstensible model for script context and directives.

[glennblock]

👍 @filipw!

[chrissie1]

Ah yes, VB, awesome.

[filipw]

we now have a dedicated repo for the new scriptcs engine based on Microsoft.CodeAnalysis libraries. https://github.com/scriptcs/scriptcs-csharp

[kasajian]

awesome!

On Sat, Mar 7, 2015 at 1:45 AM, Filip W notifications@github.com wrote:

we now have a dedicated repo for the new scriptcs engine based on
Microsoft.CodeAnalysis libraries.
https://github.com/scriptcs/scriptcs-csharp

—
Reply to this email directly or view it on GitHub
#907 (comment).

[glennblock]

Good work Filip!

[filipw]

hi all,

I have added support for Visual Basic using Microsoft.CodeAnalysis.VisualBasic and the related packages.
The code is currently in the same repo as CSharp (https://github.com/scriptcs/scriptcs-csharp/tree/master/src/ScriptCs.CSharp) since both engines share most of the traits - we'll need to figure out how we should organize it.

But - this is a reality now 😄

[filipw]

it's remarkable how easy it was - the csharp and visual basic engines differ by 4 or 5 lines of code only (!) everything else is shared

[Pilchie]

Love it!

[filipw]

I have reorganized the original C# specific repo into this https://github.com/scriptcs/scriptcs-engines/tree/master/src

It now hosts both C# and VB engines.

[paulomorgado]

Cscript allows an engine to be specified. Is this how scriptcs will support multiple engines?

[glennblock]

@paulomorgado we support multiple engines now. Engines are registered as part of a module. Modules can either load automatically based on extension, OR they can load explicitly by passing the module name as a parameter.

For example, the FSharp module loads automatically if you have it installed and have an fsx extension.

[glennblock]

Actually we also support modules which will load all the time no matter what, but I am just saying that for completeness. It doesn't affect this thread.

[filipw]

the scriptcs omnisharp has made it into omnisharp and can now be used with different omnisharp-friendly editors.

Here is a short clip showing me using it in Visual Studio Code http://recordit.co/hcmdrE43Dj

[glennblock]

Fabulous Filip!
On Fri, May 1, 2015 at 6:18 AM Filip W notifications@github.com wrote:

the scriptcs omnisharp has made it into omnisharp and can now be used with
different omnisharp-friendly editors.

Here is a short clip showing me using it in Visual Studio Code
http://recordit.co/hcmdrE43Dj

—
Reply to this email directly or view it on GitHub
#907 (comment).

[CyrusNajmabadi]

Closing out. Meeting notes don't need issues tracking them keeping them open in our issue tracker.