add debug mode

[notslang]

to optionally collect stats on compilation time for each file

[jescalan]

Hmm, could you add more details here on how you would expect the output to look and/or proposed implementation?

[notslang]

I can do one better: I'll show you! :D

this is a few lines of the jobLog:

[
  {
    "filename": "/usrdata/web/accord/test/fixtures/haml/precompile.haml",
    "engineName": "hamljs",
    "method": "compileFile",
    "duration": 0.000350218,
    "deps": [ ],
    "isolated": false,
    "time": 1405039216675
  },
  {
    "engineName": "marc",
    "method": "render",
    "duration": 0.001030628,
    "deps": [ ],
    "isolated": false,
    "time": 1405039216696
  },
  {
    "filename": "/usrdata/web/accord/test/fixtures/marc/basic.md",
    "engineName": "marc",
    "method": "render",
    "duration": 0.000211233,
    "deps": [ ],
    "isolated": false,
    "time": 1405039216698
  },
  {
    "filename": "/usrdata/web/accord/test/fixtures/marc/basic.md",
    "engineName": "marc",
    "method": "renderFile",
    "duration": 0.000532603,
    "deps": [ ],
    "isolated": false,
    "time": 1405039216698
  }
]

And this is the proposed implementation: https://github.com/slang800/accord/blob/master/lib/index.coffee#L46

It's an event emitter because having a ongoing log would basically be an intentional memory leak, and changing the return value of the promise would be really lame to just include optional info (promises can't return multiple values).

[jescalan]

Ok, so we discussed this today as well and I think the implementation we were thinking about was that we would have a compiler.deps call that would be able to go grab the dependencies, which would be cached out during compiles. Would you be willing to write out a quick example here of what you are thinking of for that interface and implementation?

[notslang]

The deps would be in the job log (under the deps property), because (usually) we don't know the deps until after the compilation is done. However, proper "tracking" for deps can be done in https://github.com/slang800/accord-watcher (which I'll be releasing a writeup for soon)

[jescalan]

Hey @slang800, just a reminder to make sure to chat with one of us about projects before starting work on them so we can be sure we are all on the same page. But of course appreciate all the thought and hard work going into this!

[notslang]

Haha, I did chat with you about it - take a look through the readme (which I published just now) & you should remember

[jescalan]

I don't remember this specific one, but looking through the readme it looks ok. How does this fit into the greater scheme of things?

[notslang]

It was a part of the conversation on July 18th before we went to "The Bridges" restaurant to celebrate Henry's internship, and was the solution for 1:many compile relations & the complexity that they would add.

Rather than adding this type of relationship to the roots core, accord-watcher would abstract file watching and file-dependency-management into a separate library, allowing the roots core to focus on more user-facing things (like setting where each file goes when compiled, and what the steps in compilation are). Though I just recently came up with the name... I only called it "a separate library" when we were talking.

As for the greater scheme of things: it's another thing to abstract out of the roots core as we break down roots into separate modules.