Thanks @ztone I'll take a look ASAP.

Thanks @adamralph,

Sorry, I was not more verbose in my first comment … it was 2 am when I sent this PR. This PR should not be merged (at least not yet), as it's more of a spike now.

The purpose for this PR is that I wanted to run a real life script file as POC for the mono engine, I was considering something like “Running bau script file to build ScriptCs on mono” … just saying that is crazy cool 😃

The problems I had when running baufile.csx was

• Verbosity
• version
• MSBuild and Exec where not found as ITaskCommand
• GetTestResultsPath function

If I removed those things the script worked.

I just want to take this route if we have good success as it will complicate other stuff (for example debug implementation, script variable scoping in REPL), but bypasses some of hard issues with the mono evaluator.

Cheers,
Stone.

Hi @ztone I grabbed this branch, rebased onto latest dev and tried it out but I ran into:

C:\code\bau-msbuild [master...origin/master]> scriptcs.exe .\baufile.csx -M mono
(25,75): error CS0103: The name CreateDirectory' does not exist in the current context (1,2): error CS0103: The name_2fc497a0_a3ec_4779_a7cf_1329296df104' does not exist in the current context

(using https://github.com/bau-build/bau-msbuild/blob/9b73f19dbb557099eddbdd6b8843a8fc8ca34b1a/baufile.csx)

I guess the first problem is the same you observed with GetTestResultsPath(), i.e. a loose method not being recognised. If I inline both CreateDirectory() and DeleteDirectory() then I get:

C:\code\bau-msbuild [master...origin/master +0 ~1 -0]> scriptcs.exe .\baufile.csx -M mono
(77,2): error CS0111: A member _0029ce70_051d_454f_a303_895c00ce20f9._0029ce70_051d_454f_a303_895c00ce20f9()' is already defined. Rename this member or use different parameter types (54,2): (Location of the symbol related to previous error) (85,2): error CS0111: A member_0029ce70_051d_454f_a303_895c00ce20f9._0029ce70_051d_454f_a303_895c00ce20f9()' is already defined. Rename this member or use different parameter types
(77,2): (Location of the symbol related to previous error)
(93,2): error CS0501: _0029ce70_051d_454f_a303_895c00ce20f9._0029ce70_051d_454f_a303_895c00ce20f9()' must have a body because it is not marked abstract, extern, or partial (1,2): error CS0103: The name_0029ce70_051d_454f_a303_895c00ce20f9' does not exist in the current context

I'm still a little hazy on how all this works. I think we may need @filipw to chime in since he wrote the initial mono engine implementation.

One thing that does initially concern me is that, with this change, the script that gets compiled diverges from that which is written. E.g. If I use the latest dev build I get an output like:

C:\code\bau-msbuild [master...origin/master]> scriptcs.exe .\baufile.csx -M mono
C:\code\bau-msbuild\baufile.csx(23,40): error CS0584: Internal compiler error: Object reference not set to an instance of an object.

I.e. I can relate the message back to a line in a file. But with this change I get:

C:\code\bau-msbuild [master...origin/master]> scriptcs.exe .\baufile.csx -M mono
(25,75): error CS0103: The name CreateDirectory' does not exist in the current context (1,2): error CS0103: The name_2fc497a0_a3ec_4779_a7cf_1329296df104' does not exist in the current context

• the filename is no longer mentioned
• the CreateDirectory() call isn't on line 25, it's on line 23. The extra artifacts that have been added have shunted it down.
• _GUID doesn't relate to anything in the file

@adamralph Thanks for looking into this.

Can you grab the lastest and check if it works for you now. I've added support for loose functions.
I managed to build Bau.MSBuild with baufile.csx after these changes.

This is just an experimental spike. I just want to know if this is usable before continuing.
I know there is stuff to do to make this user friendly, as you pointed out.

Thanks again.
Stone.

OK, it now works for the bau-msbuild baufile! 👍

Unfortunately it still fails on the build script for the core Bau project

(using https://github.com/bau-build/bau/blob/7b0e3a080f324d6a40b710f161fca76c7ea02d18/baufile.csx)

C:\code\bau [dev...upstream/dev]> scriptcs.exe .\baufile.csx -M mono
(107,3): error CS1547: Keyword 'void' cannot be used in this context
(1,6): error CS0246: The type or namespace name '_f4d39eac_4989_46c8_9f85_776bd6d73860' could not be found. Are you missing an assembly reference?

Thanks for testing this @adamralph

This flushed out an issue I've known about that I think we need to deal with. The issue is how NRefactory is parsing blocks { }. See for example SyntaxtreeParserTests line 160, a test that hasn't been solved.

What is causing baufile.csx to fail here is

.Task("default").DependsOn(string.IsNullOrWhiteSpace(ci) 
  ? new[] { "unit", "component", "pack" } 
  : new[] { "unit", "component", "accept", "pack" })

If you move the condition to a function

string[] IsCI(string ci)
{
    return string.IsNullOrWhiteSpace(ci) 
        ? new[] { "unit", "component", "pack" } 
        : new[] { "unit", "component", "accept", "pack" }
}

it should work. It's the block inside DependsOn method that is causing the NRefactory parser to fail.

Another issue with NRefactory I found yesterday is that it removes statements it can't parse inside classes e.g. class A { this_should_not_parse } NRefactory will output as class A { } and thus will not return a compile error.

NRefactory wasn't built for scriptcs syntax, but what it does really well is converting methods into names function expressions so we can use loose functions in mono.

I've been fiddling around with a simple pre-lexer that should help with the above issues. The idea is to use the pre-lexer is to extract classes, methods and evaluations from the code, instead of NRefactory. Doing this will give us more flexibility to handle the syntax but will probably take awhile to flush out all the bugs. However, it looks like the lexer doesn't have to be very sophisticated to handle this.

It's been really helpful to have a real script been pushed through the mono engine.
Thanks again.

Interesting stuff! It would be great to wrap all this up to bring unformity with the Roslyn and Mono engines (it's something we've been discussing as a prereq. for 1.0) but it certainly appears to be quite involved...

Thanks @ztone for the putting effort into this. Please keep us posted! Do you want this PR left open or has it served its purpose for now?

Yes, I think it has served it purpose and can be closed now.

Great. Looking forward to seeing the pre-lexer!