search

enjalot / tributary

rapid prototyping with d3.js
http://tributary.io
Other
598 stars 71 forks source link

Improvements to Tributary for CoffeeScript, Workflow, Error handling #129

Closed eldrgeek closed 9 years ago

eldrgeek commented 9 years ago

There are a lot of changes in this pull request, and I apologize for not making this more granular. But here's the package:

  1. The "execute" event is triggered many times during startup which can cause problem, for example when you self-reference the editor or reference a plugin before it's loaded. I set a flag pluginsLoaded in inlet_handlebars to set this flag after the plugins are loaded, and guards in CoffeeContext for these two conditions. I think that loading plugins is the last initialization activity. If there was a way to suppress "execute" events until pluginsLoaded is true, that would be better.
  2. Fixed a bug in the inline-console plugin. It assumes that all widgets come from the same context (and thus same editor). Changed the plugin so that the clearLine function matches on line number and on cm editor. The call to clear all widgets was in the "onrender" callback. But that is nowhere in the code. I changed it to "pre:execute"
  3. Upgraded CoffeeScript to 1.9 both in package.json by copying the browser version into static/lib/coffee-script.js. This permits source maps and generators (with a browser that supports generators) among other things.
  4. CoffeeScript compile error messages now appear in the CoffeeScript inlet editor. Originally done using inline-console's logJack function, but I changed it because error feedback wants to be in two parts a ^ under the starting token column, and the message itself. Plan to add CoffeeLint like you have done on JSLint
  5. Third argument (persist) added to console.logJack so you can have it add a line, rather than replace the current line.
  6. Added console.logHTML so I could write two lines as a unit with arbitrary innerHTML, and a log-html CSS class with different coloring (error-like, for now) and without the indent and ">" I will remove the indent and ">" properties from the inline-console class CSS
  7. CoffeeScript runtime error messages now appear in the CoffeeScript inlet editor. The code for this has a bug which I will fix shortly. If the error is in a line in the inlet script, then the error is displayed at the right place. If the error is in a called routine, it is displayed on the first line in the inlet. It should display the error at the line where the call was done.
  8. When using the CoffeeScript editor, If the word 'debugger' appears on its own line in the JS then sourceMaps are added to the compiled coffeescript. This lets you debug in coffeescript rather than JS. This should really be done by messing with the tree, as you are doing with console.log in the plugin. Note: the reason I do it only when debugger is in the code is that the name of the file has to be changed each time, because Chrome (at least) treats each instance separately and does not get rid of old instances.
  9. context argument added to evaluated CoffeeScript function. This lets me modify some of the extension methods that I've created from within Tributary.
  10. Improved workflow. Created shell script runtributary to watch the server and monitor files. If the server.js file or settings.js are changed, then the server is restarted. If any of the src files are changed then the current page is reloaded. More complete documentation is in static/reload/README.md I will add this information to the Wiki later.
enjalot commented 9 years ago

this is awesome! i look forward to merging in!

since we dont have tests i generally use representative inlets. do you have any i can reference to try out the new features?

thanks! On Feb 28, 2015 6:11 PM, "EmbeddedMike" notifications@github.com wrote:

There are a lot of changes in this pull request, and I apologize for not making this more granular. But here's the package:

  1. The "execute" event is triggered many times during startup which can cause problem, for example when you self-reference the editor or reference a plugin before it's loaded.

I set a flag pluginsLoaded in inlet_handlebars to set this flag after the plugins are loaded, and guards in CoffeeContext for these two conditions. I think that loading plugins is the last initialization activity.

If there was a way to suppress "execute" events until pluginsLoaded is true, that would be better.

  1. Fixed a bug in the inline-console plugin. It assumes that all widgets come from the same context (and thus same editor). Changed the plugin so that the clearLine function matches on line number and on cm editor. The call to clear all widgets was in the "onrender" callback. But that is nowhere in the code. I changed it to "pre:execute"

    1.

    Upgraded CoffeeScript to 1.9 both in package.json by copying the browser version into static/lib/coffee-script.js. This permits source maps and generators (with a browser that supports generators) among other things. 2.

    CoffeeScript compile error messages now appear in the coffeescript inlet editor. Originally done using inline-console's logJack function, but I changed it because error feedback wants to be in two parts a ^ under the starting token column, and the message itself.

Plan to add CoffeeLint like you have done on JSLint

1.

Third argument (persist) added to console.logJack so you can have it add a line, rather than replace the current line. 2.

Added console.logHTML so I could write two lines as a unit with arbitrary innerHTML, and a log-html CSS class with different coloring (error-like, for now) and without the indent and ">"

I will remove the indent and ">" properties from the inline-console class CSS

  1. When using the CoffeeScript editor, If the word 'debugger' appears on its own line in the JS then sourceMaps are added to the compiled coffeescript. This lets you debug in coffeescript rather than JS.

This should really be done by messing with the tree, as you are doing with console.log in the plugin.

Note: the reason I do it only when debugger is in the code is that the name of the file has to be changed each time, because Chrome (at least) treats each instance separtely and does not get rid of old instances.

  1. Improved workflow. Created shell script runtributary to watch the server and monitor files. If the server.js file or settings.js are changed, then the server is restarted. If any of the src files are changed then the current page is reloaded. More complete documentation is in static/reload/README.md

I will add this information to the Wiki later.

You can view, comment on, or merge this pull request online at:

https://github.com/enjalot/tributary/pull/129 Commit Summary

  • Autoload pages and autostart server on changes
  • Merge remote-tracking branch 'upstream/master'
  • Uupdated package.json and documentation for reload
    1. Added pluginsLoaded after plugins loaded to avoid premature execution

File Changes

Patch Links:

— Reply to this email directly or view it on GitHub https://github.com/enjalot/tributary/pull/129.

eldrgeek commented 9 years ago

That's a great way to do it. I will create some inlets today to cover the feature set. Mike

On Tue, Mar 3, 2015 at 12:46 PM, Ian Johnson notifications@github.com wrote:

this is awesome! i look forward to merging in!

since we dont have tests i generally use representative inlets. do you have any i can reference to try out the new features?

thanks! On Feb 28, 2015 6:11 PM, "EmbeddedMike" notifications@github.com wrote:

There are a lot of changes in this pull request, and I apologize for not making this more granular. But here's the package:

  1. The "execute" event is triggered many times during startup which can cause problem, for example when you self-reference the editor or reference a plugin before it's loaded.

I set a flag pluginsLoaded in inlet_handlebars to set this flag after the plugins are loaded, and guards in CoffeeContext for these two conditions. I think that loading plugins is the last initialization activity.

If there was a way to suppress "execute" events until pluginsLoaded is true, that would be better.

  1. Fixed a bug in the inline-console plugin. It assumes that all widgets come from the same context (and thus same editor). Changed the plugin so that the clearLine function matches on line number and on cm editor. The call to clear all widgets was in the "onrender" callback. But that is nowhere in the code. I changed it to "pre:execute"

Upgraded CoffeeScript to 1.9 both in package.json by copying the browser version into static/lib/coffee-script.js. This permits source maps and generators (with a browser that supports generators) among other things. 2.

CoffeeScript compile error messages now appear in the coffeescript inlet editor. Originally done using inline-console's logJack function, but I changed it because error feedback wants to be in two parts a ^ under the starting token column, and the message itself.

Plan to add CoffeeLint like you have done on JSLint

1.

Third argument (persist) added to console.logJack so you can have it add a line, rather than replace the current line. 2.

Added console.logHTML so I could write two lines as a unit with arbitrary innerHTML, and a log-html CSS class with different coloring (error-like, for now) and without the indent and ">"

I will remove the indent and ">" properties from the inline-console class CSS

  1. When using the CoffeeScript editor, If the word 'debugger' appears on its own line in the JS then sourceMaps are added to the compiled coffeescript. This lets you debug in coffeescript rather than JS.

This should really be done by messing with the tree, as you are doing with console.log in the plugin.

Note: the reason I do it only when debugger is in the code is that the name of the file has to be changed each time, because Chrome (at least) treats each instance separtely and does not get rid of old instances.

  1. Improved workflow. Created shell script runtributary to watch the server and monitor files. If the server.js file or settings.js are changed, then the server is restarted. If any of the src files are changed then the current page is reloaded. More complete documentation is in static/reload/README.md

I will add this information to the Wiki later.

You can view, comment on, or merge this pull request online at:

https://github.com/enjalot/tributary/pull/129 Commit Summary

  • Autoload pages and autostart server on changes
  • Merge remote-tracking branch 'upstream/master'
  • Uupdated package.json and documentation for reload
    1. Added pluginsLoaded after plugins loaded to avoid premature execution

File Changes

Patch Links:

— Reply to this email directly or view it on GitHub https://github.com/enjalot/tributary/pull/129.

— Reply to this email directly or view it on GitHub https://github.com/enjalot/tributary/pull/129#issuecomment-76995945.

enjalot commented 9 years ago

I went through your inlets: http://tributary.io/s/6094415?user=EmbeddedMike (fyi, if you create tributary inlets in localhost they wont show up in these production views because this uses the production database)

everything seemed to work fine with the pull request except this one: http://tributary.io/inlet/34d645bc095fe4ca759c which looks like the new version of coffeescript is a little more strict on some of the syntax?

anyway it looks pretty good to me, thanks so much for the contributions!

enjalot commented 9 years ago

I'm a little wary of including livereload in the production server though. is there a way to make sure it doesnt load then? or can we have a environment variable that turns it on locally when you run with ./runtributary?

enjalot commented 9 years ago

unfortunately i can't deploy it this weekend... I'm traveling and apparently this work laptop doesnt have the ssh key to get into the server =\ more time for you to make more thorough test inlets ;)

eldrgeek commented 9 years ago

Ian, It should not be a problem, but if you want I will make the change. Here's the story:

The code that I added to the server for livereload is:

livereload = require('livereload'); //Print debug messages, and watch 'md' files server = livereload.createServer({debug: true, exts:['md']}); server.watch(__dirname + "/static");

That means that the livereload server watches the files in the static directory for changes, and only then will send a message to the plugin telling it to reload.

AFAIK (and you are the expert) the static directory is only changed during the make process, and that only happens in development.

But even if there were changes, it would not do anything unless the livereload plugin had been installed, and was enabled for a tributary page.

So to summarize: to livereload all three things have to happen:

  1. Change file in static directory
  2. Plugin installed by user
  3. Plugin enabled by user, for that page

So I think program logic says 1 would not happen, and 2, and 3 are under user control.

All that said, I will defer to you and if you want me to add an environment variable or put it under switch control I will do that.

On Fri, Mar 13, 2015 at 12:39 AM, Ian Johnson notifications@github.com wrote:

I'm a little wary of including livereload in the production server though. is there a way to make sure it doesnt load then? or can we have a environment variable that turns it on locally when you run with ./runtributary?

— Reply to this email directly or view it on GitHub https://github.com/enjalot/tributary/pull/129#issuecomment-78796276.