bin/traceur.js has insignificant diffs that confuse commits #423
Comments
|
No, it looks like the list of files is loaded async then compiled as a unit in order. |
|
Should |
|
@rosshadden You need a binary that is able to compile traceur itself. Since Traceur uses ES6 we need to keep this binary up to date (at least up to date enough to compile traceur). |
|
@arv Do you know what causes the different event turns in traceur? If I print the oldest stack frame when generateUniqueIdentifer() is called I see changes, but I don't see what queues that first call. Its usually transformAny or transform. |
|
@johnjbarton Yeah, I would think most of these comes from the transformers (most commonly TempVarTransformer). These gets called from from the CodeLoader which is async. Maybe you could log the order in which the files get transformed? If that is not stable there is no way that the ids will be stable. |
|
Here is a trace of the file loads and id generation. A lot of the ids never appear in the generated source. So some of the diffs we don't like could be real: compiler changes could cause more or less extraneous id generation. The diffs that are surely unreal are those that appear after we clone master and build fresh: we should never see diffs if the compile is deterministic. Changes to load order should result in id diffs and in blocks of generated code shifted. We mostly see the first sometimes the second. Just now I cloned git@github.com:google/traceur-compiler.git on my linux box and on my Mac Air. Both gave diffs after |
|
Here is the diff of the mac air and linux logs. Transform order differs. |
|
It looks like we transform the files on the command line in order then src/traceur.js. The remainder are not in order. But the remainder are all transformed after all of the loads. So there should be no penalty for transforming in some fixed order. |
|
@arv From what I can tell the dependency graph in module-loader is implicit in the order of entries to the arraymap "cache". The first codeunit arrives from the network (fs) and is pushed into the cache. It is parsed and its dependencies are pushed and queued for loading. When all of the values in the cache are parsed, we begin at the front and transform. Thus we are assured that all of the dependences are available during transform and immediate dependencies are ordered but the order of dependencies of dependencies vary with load order. I think that maintaining the dependency graph would solve the current issue and it would be useful for diagnostic messages. Each codeunit would have an array of dependencies ordered by the parse and the transform would operate in that order (depth first). I don't think it would add significant overhead, just an array of pointers per codeunit. Am I on the right track? |
|
That sounds like it would work.
|
ghost
assigned 
I believe the diffs we see are caused by using src/node/inline-module.js inlineAndCompile() on the file list $(SRC) in$(TFLAGS) $ (SRC)
./traceur --out bin/traceur.js
inlineAndCompile loads files async, then compiles them. The compiler uses generateUniqueIdentifier from src/codegeneration/UniqueIdentifierGenerator.js which issues numbers serially from zero. Compilation order changes cause identifier changes.
I'm not 100% because the diffs ought to be larger in most cases. But notice that the diffs do seem to be equal number of adds and deletes.
The text was updated successfully, but these errors were encountered: