munificent

// On my laptop, I get:
// getter run 1: 73ms
// getter run 3: 64ms
// getter run 11: 63ms
// getter run 12: 14ms
// getter run 30: 13ms
// field run 1: 68ms
// field run 7: 64ms
// field run 9: 63ms

munificent

library logger;

import 'verbose.dart';
import 'plain.dart';

log(message) {
  print(const String.fromEnvironment("logger.level"));
  if (const String.fromEnvironment("logger.level") == "verbose") {
    logVerbose(message);
  } else {

munificent

Scenario: Kevin and Erik or some other fine contributor to the async_await package on GitHub has committed some changes and you want to use those within the main Dart repo.

About you:

• You already have the repo downloaded locally on your machine.
• You are using Git, not svn. You also probably ride a horseless carriage and no longer use leeches and bloodletting to cure your ailments.

Note that you do not need a separate svn checkout. You already have one, you just don't know it.

Given that, here's the process. This likely alsos work for other third party packages that live on GitHub that we want to use in the Dart repo, but I make no promises there:

munificent

I'm starting to think through how pub can interop with bower and other package managers. I'm calling these "foreign" packages. I have a strawman here I want to get feedback on. It's based heavily on earlier work from John Messerly and Justin Fagnani.

High level goals

• Your application can depend on stuff from other package managers. I'm initially targeting bower, but I want this to be open-ended.

• Your application can depend on pub packages which in turn depend on stuff from other package managers.

• You can depend on foreign packages which in turn have their own (foreign) dependencies.

munificent

someAsyncThing.then((_) => itWorked())
  ..catchError((error) {
  handleError();
});

munificent

You appear to be advocating a new:

[ ] cloud-hosted [ ] locally installable [ ] web-based [ ] browser-based [ ] language-agnostic
[ ] language-specific IDE. Your IDE will not succeed. Here is why it will not succeed.

You appear to believe that:
[ ] Syntax highlighting is what makes programming difficult
[ ] Garbage collection is free
[ ] Computers have infinite memory
[ ] Nobody really needs:

munificent

Spent a bunch of time talking to Nathan, Siggy, and Kevin about how to handle pub serve with stuff outside of web/. Our goals are:

1. Root-relative URLs inside web/, test/, example/, and even things like subdirectories of example/ should be supported. This means that the root directory being served needs to be constrained to those.

   We can't require the user to hit localhost:8080/example/example1/foo.html because it would break a root-relative URL in foo.html.

2. More than one of these directories needs to be servable simultaneously. If you have to shut down the server and restart it (which entails rebuilding

munificent

I spent a bunch of this morning talking with Siggy and Nathan about asset-handling in pub. It's still pretty rough in many places, and we're trying to figure out how to smooth that out. The questions that started this (brought up on this thread) were:

1. Can you have non-dart files in a lib/ directory?
2. If so, where do they end up when you run pub build?

Since, I love transparency and feedback, and because many of the constraints pub operates under aren't obvious, I thought it might be cool to walk through our thoughts.

What's with "lib" and "packages"?

When we initially created pub, well before we did any work on assets, the only goal of the system was to be able to re-use Dart code.

munificent

I'm starting to work on a new pub command. I've got two goals for it.

Use case 1: Pre-populating your cache (bug #16265)

The first is that it can be used to install a package into your system cache. For example, maybe you're about to go off the grid and you want to make sure you have a bunch of stuff cached locally before you fall off the Internet. pub get does this implicitly, of course, but you may not have any packages that depend on the stuff you're downloading. You just want to pull it down.

Our specific use case is that we are starting to run tests of packages. Since hitting the network can fail, we'd like to do that separately from running pub get so that we can handle the failure more gracefully.

The idea is you could do:

munificent

Pub has two commands for working with transformers, build and serve. Both of those currently are hardcoded to only see stuff in your package's web/, asset/, and lib/ directories. We've been wanting to have support for test/, example, and others for a while (see #14673 and #15924). This sketches out what I'm thinking to handle this. Feedback is welcome!

The basic idea is that build and serve will be able to see of these directories: asset/, benchmark/, bin/, example/, test/, and web/. Transformers will be able to run on assets in any of those.

The build/ directory

Right now, pub build creates a build/ directory containing the output of the build process. That directory only contains the outputs whose path is within web/. If we start building tests and examples into there, stuff could start colliding.

So the first change is that we'll reorganize the build/ directory to match your package. Outputs within web/ will