munificent

#1 JavaScript
#2 Ruby
#3 Java
#4 Shell
#5 Python
#6 PHP
#7 C
#8 C++
#9 Perl
#10 CoffeeScript

munificent

#1 JavaScript
#2 Ruby
#3 Java
#4 Shell
#5 Python
#6 PHP
#7 C
#8 C++
#9 Perl
#10 CoffeeScript

munificent

// This is a Dart solution to:
//
// Nick Parlante's "Great Tree-List Recursion Problem"
// http://cslibrary.stanford.edu/109/TreeListRecursion.html
//
// Before you read the code here, try to solve it youself first!

main() {
  var tree = makeTree(100);
  printTree(tree);

munificent

#include <stdlib.h>
#include <time.h>

// This tests a simulated game loop with a bunch of different memory
// configurations. You have a bunch of actors. Each actor has a few components.
// Each frame every component for every actor is updated. Except for "wrong
// order", all components of the same "type" are update for each actor.
// In other words, it updates component #1 for every actor, then component #2,
// etc.
//

munificent

I downloaded the most recent versions of every package on pub a few weeks ago.
Then I ran cloc on them. Here's the stats:

     packages:       558
  .dart files:     9,519
comment lines:   215,179
  blank lines:   279,407
   code lines: 1,028,710
        total: 1,523,296

munificent

diff --git a/src/wren_compiler.c b/src/wren_compiler.c
index cbb9ca6..83420f1 100644
--- a/src/wren_compiler.c
+++ b/src/wren_compiler.c
@@ -1600,6 +1600,24 @@ void block(Compiler* compiler)
   emit(compiler, CODE_POP);
 }

+// Defines a default constructor method with an empty body.
+static void defaultConstructor(Compiler* compiler)

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

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

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

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