Cannot run dev_compiler on Windows - Exception thrown

[daniel-v]

dev_compiler version: 0.1.5+1
System: Win 8.1

As per the recommendation here, I was trying to execute:
pub global run dev_compiler:devc -o outputdir --server file.dart

This is what I see in console:

Unhandled exception:
Uncaught Error: Invalid argument(s): Path must start with '/'
Stack Trace:
#0      MemoryResourceProvider.newFolder (package:analyzer/file_system/memory_file_system.dart:129)
#1      MemoryResourceProvider.newFile (package:analyzer/file_system/memory_file_system.dart:113)
#2      _createImplicitEntryResolver (package:dev_compiler/src/server/server.dart:291)
#3      DevServer.DevServer (package:dev_compiler/src/server/server.dart:214)
#4      compile.<compile_async_body> (package:dev_compiler/src/compiler.dart:71)
#5      Future.Future.microtask.<anonymous closure> (dart:async/future.dart:144)
#6      _microtaskLoop (dart:async/schedule_microtask.dart:43)
#7      _microtaskLoopEntry (dart:async/schedule_microtask.dart:52)
#8      _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:96)
#9      _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:149)

#0      _rootHandleUncaughtError.<anonymous closure> (dart:async/zone.dart:895)
#1      _microtaskLoop (dart:async/schedule_microtask.dart:43)
#2      _microtaskLoopEntry (dart:async/schedule_microtask.dart:52)
#3      _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:96)
#4      _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:149)

I dag a bit into it. It seems like that the in the analyzer's memory_file_system.dart file, posix path context is used. This little example will demonstrate why that won't work on windows:

import 'package:path/path.dart';

void main() {
  final String sillyWinPath = 'C:\\Users\\Daniel\\Documents\\Projects\\pretty.jpg';
  var posixDirName = posix.dirname(sillyWinPath);
  var winDirName = windows.dirname(sillyWinPath);
  print("$winDirName | $posixDirName");
  //> . | C:\Users\Daniel\Documents\Projects
}

[jmesserly]

good catch. does it only happen with --server or do you see it from the batch compiler as well?

[daniel-v]

No, this exception does not occur when running the command without --server argument. However I get another one, that's at least as pretty! :)

Unhandled exception:
Uncaught Error: Invalid argument(s): join(null, "harmony_feature_check.js"): part 0 was null, but part 1 was not.
Stack Trace:
#0      _validateArgList (package:path/src/context.dart:572)
#1      Context.join (package:path/src/context.dart:210)
#2      join (package:path/path.dart:225)
#3      BatchCompiler._copyDartRuntime (package:dev_compiler/src/compiler.dart:182)
#4      BatchCompiler.compileLibrary (package:dev_compiler/src/compiler.dart:146)
#5      BatchCompiler.compileLibrary (package:dev_compiler/src/compiler.dart:152)
#6      BatchCompiler.compileSource (package:dev_compiler/src/compiler.dart:139)
#7      BatchCompiler._compileFromUri (package:dev_compiler/src/compiler.dart:131)
#8      BatchCompiler.compileFromUriString (package:dev_compiler/src/compiler.dart:120)
#9      Object&ListMixin.forEach (dart:collection/list.dart:63)
#10     BatchCompiler.run (package:dev_compiler/src/compiler.dart:111)
#11     compile.<compile_async_body> (package:dev_compiler/src/compiler.dart:77)
#12     Future.Future.microtask.<anonymous closure> (dart:async/future.dart:144)
#13     _microtaskLoop (dart:async/schedule_microtask.dart:43)
#14     _microtaskLoopEntry (dart:async/schedule_microtask.dart:52)
#15     _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:96)
#16     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:149)

#0      _rootHandleUncaughtError.<anonymous closure> (dart:async/zone.dart:895)
#1      _microtaskLoop (dart:async/schedule_microtask.dart:43)
#2      _microtaskLoopEntry (dart:async/schedule_microtask.dart:52)
#3      _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:96)
#4      _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:149)

The command was:
pub global run dev_compiler:devc -o ..\outputdir file.dart

I managed to verify that in this situation, the options.runtimeDir in compiler.dart:182 is null, thus the validation will of course fail.
Did I miss a configuration option with which I provide the Dart runtime to dev_compiler?

Update:
by manually specifying the --runtime-dir argument to point to the folder of dev_compiler's runtime folder in the pub cache, I managed to execute the compilation. From what I saw, the runtime directory should be configured automatically, or at least there is an attempt to do so. I guess this exception is more of a runtime directory is not configured automatically on windows kind.
In options.dart:332, new File(lockfile).existsSync() fails, the _computeRuntimeDir will return null. That's why runtimeDir option is null by default.

Would you rather this be a new issue?

[jmesserly]

Would you rather this be a new issue?

Either way works :) ... I can take a look at these.

Ah, I forgot about that _computeRuntimeDir code... funny, yeah, I suspected that code was really buggy :| ... tried to remove it once but did not succeed. Was waiting on the new Resource class but I don't think it's implemented yet. In the meantime I'll see if there's a simple fix.

[jmesserly]

ouch... I'm pretty sure the _computeRuntimeDir bug happens on all platforms. Pub does not seem to create a lockfile anymore for "pub global activate", or at least, not in the place that we expect to find it. And "pub run dev_compiler:dartc" doesn't work either. I'll file a bug.

EDIT: strange, it doesn't reproduce on Mac, but I don't understand why. Directory layout looks identical to Windows. I'm super confused.

[jmesserly]

Think I've found a fix for the batch compiler issue, looking at the server problem

[jmesserly]

I think this fixes both issues (as well as --server breakage in 0.1.5) https://codereview.chromium.org/1270993002/

if not we can keep iterating :)

[daniel-v]

Wow, that was quick! :) Let's hope I don't run into more issues and thanks. Will this commit make it into a patch version or should I just pull master and use that?

[donny-dont]

@jmesserly tested on winders and its looking good. Hadn't seen the output before and I'm pretty impressed.

One question though is the \ correct? Wondering if its another fun winders thing.

dart_library.library('src\convert\story_comment_convert', null, /* Imports */[
  "dart_runtime/dart",
  'dart/convert',
  ...

And just curious but I'm kinda curious is there something recommended for running the output through to get to ES5?

[jmesserly]

hmmmm. that might be wrong. does the forward vs backslash match up with the import path? If so, it might work because those strings are just identifiers. But still, I'm guessing nodejs and ES6 would prefer that to be a URL style path. I'll take a look.

[jmesserly]

clarification: what I mean is, if you have a library that imports that guy as 'src\convert\story_comment_convert' ... then it will probably work, even though it doesn't look right.

And just curious but I'm kinda curious is there something recommended for running the output through to get to ES5?

Hmmm. I suspect BabelJS or Traceur would work, since we're testing in Chrome, so it's definitely valid ES6. But I haven't tried it.

One thing that's really odd right now is our module pattern. I'd like to have an option of one of the standard ES5 patterns, or at least use ES6 modules (because then Babel would understand it and offer a bunch of desugarings). Unfortunately I don't think modules are supported in Chrome Canary yet, so that complicates things a bit for us. Ideally was going to fix #34 properly, but that's blocked on Chrome support, which in turn is blocked on having a spec for module loaders. DOH.

Anyway, that digression aside, thanks for trying it out! Let me know how it goes...

[jmesserly]

Hadn't seen the output before and I'm pretty impressed.

thanks! if you have any ideas for improving it, definitely let me know. One things that might help but isn't implemented yet: being able to import names unqualified. Also I think the not-null-by-default DEP will be a huge help. We also have a bug open for preserving comments, but I haven't found a way to fit it in that felt reliable.

Oh, also, I'm going to open a bug for that backslash issue. Should be cross linked here shortly.