Keeping it short since it's really late. Did a bit of Ember.js with Go and finally understand how Ember templates have to be included since there isn't an asset pipeline that embeds the Handlebars templates into the file. I could add that to pipeln, but that means I'll need to get more into filters to allow it to be extensible.
I then spent a fair amount of time with MSP430 Forth running it on an MSP430G2553 setting breakpoints and single stepping. Things seem to work up to a point, and I figured out where it's failing. However, I'm not 100% sure what needs to happen to fix it. Need to sleep on it.
I should have realized this, but using something newly written is a great way to get distracted by finding bugs in it. I spent most of my time fixing issues that cropped up in pipeln. On the plus side, it makes that project better. On the flip-side, I didn't really get that much done with Ember.js tonight. I did get a little done, but it felt like there was a fair amount of time getting my tmux session and VIM ctrlspace workspace(s) setup.
Most of the time was working on an Ember.js application and really getting everything ready to go to fully start learning the framework. During this process I fixed a couple issues with pipeln's javascript loading via requires. One issue was it wasn't processing a file that was included with a require. However, require_tree seemed to be working as expected. Looking at the code, it ended up being pretty obvious that the processing wasn't being called there, but it was being called from the require tree function.
Once that was fixed, things started loading, but the javascript was then breaking on the client side. Turns out, another thing I sort of arbitrarily decided when writing the initial implementation of the asset loader was to collect all require statements, then go though each processing as required, and finally prepending them to the file.This can pretty easily cause errors with undefined variables after it's loaded into the browser. My solution was to include the files processed from require/require_tree statements at the site they're declared at. This way, if the require is at the bottom of the file, it loads the file at the bottom.
I also played around a little with Bourbon, Neat, & Bitters in so far as to give up on them for now since the Sass processing isn't built into pipeln yet. I briefly looked at options for building them outside of that. Manually compiling the Sass also only yielded about 200 lines of CSS with the imports for the three libraries. As that seemed like a mistake, I decided to table that for now and go with Bootstrap.
Earlier today I spent some time with MSP430 Forth cleaning up some things and committing some code that's been hanging out uncommitted for several days now.
Implementing the require_tree was fairly trivial since everything else was basically in place. I was able to make use of filepath.Walk to just walk the files and then run the Javascript processor over the files, one by one.
There are still a few issues with the implementation. For instance, using a require_tree .. is likely going to crash. The easy solution would be to disallow going up directories. A perhaps better solution would be to checksum the files, store that in a hash, and only process files that don't match a processed checksum. This is going to be slower, but should provide a better experience when using it.
Other things that still need to be done are:
Other things that might be interesting. Getting the baseline application layout from ember-rails, getting the uncompressed jQuery, HTMLBars, & Ember.js, and then loading them from application.js with appropriate requires; everything seems to work as expected. It'll be faster, to include these normally, but it's a slightly interesting point of reference that it processed 2020288 bytes in about 20ms. Honestly, this was the end goal I was really hoping to accomplish with this project. I was really wanting to play with Ember from a non-Rails application (specifically in Go) that had Sprockets-like autoloading of Javascript files for quick iterations. The project will likely be going on Github in the next few days after I write some documentation & tests for it.
