Tributary and CoffeeScript

[Mike Wolf]

Ian,

The current version of Tributary uses an OLD version of CoffeeScript, before there were source maps.

I want to change this, so I can get line numbers for errors, and things, but it's not entirely obvious how to do this.

I really liked the idea of inline logging, but when I read the code I found that you'd done it by hacking the JS compiler.

I have a design for a mechanism that will work for CoffeeScript.

My proof of concept is in this inlet:

   http://tributary.io/inlet/87aee8499c18958c8293

I grab console.log and replace it with a function that does what I want. My function needs to be modified so that it gets the source location of the caller.

Currently the version of Coffee that's loaded in the browser if from pre-source-map days. I want to update this.

I can Kludge it by just getting the file and copying it into static/lib/coffee-script. Better might be to use Bower. I don't know.

Here's what I found out:

1. package.json has 1.6.2, which is after Source Maps were added

2. static/lib/coffee-script.js is version 1.3.3, which is before then, and that's what gets loaded in the browser.

To run a test, I grabbed  

    http://cdnjs.cloudflare.com/ajax/libs/coffee-script/1.6.2/coffee-script.min.js

as a library, and ran tests in this inlet:

   http://tributary.io/inlet/87aee8499c18958c8293

3. The current version is 1.7.1.

Let me know where the browser-side coffee comes from and I will give you a pull request

Mike

[Ian Johnson]

Hi Mike,

Yeah, we should probably be requiring everything, but for now the easiest thing to do is probably replace the /static/lib/coffee-script.js with the latest version, as well as upgrade the package json.

If we use source maps we should be able to modify the inline-logging plugin to go from the js line number to the coffee line number and add the widget there instead right?

--
You received this message because you are subscribed to the Google Groups "Tributary" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tributary+...@googlegroups.com.
Visit this group at http://groups.google.com/group/tributary.
For more options, visit https://groups.google.com/d/optout.

--

Ian Johnson - 周彦

http://enja.org

[Ian Johnson]

to be more specific, i downloaded the browser-side coffee-script from the coffeescript github and pasted it into the tributary repo...

[Mike Wolf]

Because I use Coffee mainly, I've done a bunch of experiments in the CoffeeContext

Because I haven't heard from you I did the changes in my own checkout.

I have some cleanup to do (probably another day) and can send you one or more pull requests

For my convenience it's best if I can send you just one or two pulls, but ideally there should be many and smaller. That's extra work for me, but I will do that if you want it.

Here's the stuff I've been working on. 

Please comment back.

Glad to hear from you.

Mike

1. I fixed a bug that comes up when you self-reference the editor and it runs before the editor has been assigned. I return from CoffeeContext if no editor I Assume that this same thing should be done for JSContext. 
• Comment?
  
2. Stepping through the code in the debugger it appears that the .exec function is called several times before plugins are loaded. 
• What is the best way to ensure no execution until everything is loaded?
  
3. I 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.
   
4. The call to clear all widgets was in the "onrender" callback. But that is nowhere in the code. I changed it to "pre:execute" 
• Will that work right? Or will there be a problem if there are two different contexts (say JS and CS) running?
• Should it be both "onrender" and "pre:execute"
5. I made a change so that CoffeeScript compile error message in the coffeescript 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. 
• May need to change the clear-widgets code to clear the error messages separately since they might appear on different lines
  
• Made the below changes in the course of making this change
• Plan to add CoffeeLint like you have done on JSLint
6. Experimental: Third argument (persist) added to console.logJack so you can have it add a line, rather than replace the current line
• Leave in or take out? No longer needed.
7. Added console.logHTML so I could write two lines as a unit with arbitrary innerHTML
• Added a log-html CSS class with different coloring (error-like, for now) and without the indent and ">"
• Can I remove the indent and ">" properties from the inline-console class CSS I don't think they add any value
8. Passing the context as a third parameter, like g and tributary to initialize function. This lets me access the context's state without having to make an explicit reference
   
9. If the word 'debugger' appears on its own line in the JS then I add sourceMap 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. 
• For now is this hack OK?
• 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. 
10. When I ran into the bug (1 above) I tried to work around it by hacking the gist at github, but kept reloading the same thing. Finally, later on read the server code and saw it is caching gists.
• What about adding a new API function that clears the cache. Or does something already do this?
  
11. My Dev cycle for working on tributary is pretty awful and I need to change it. Currently I switch to my editor window (Sublime) and make the change. Move to a console window and run make. Back to browser window and reload. I need to improve this. 
• Do you have something already working that is better? 
• If not, I'd propose to run one of the node packages that monitor files for changes, and then does stuff. I'd have it run jslint and the make and if successful signal the server to force a reload.
• Later, would like to make changes so most of the time one just works in Tributary. The following is a first step:
12. Plugins would be built and maintained in Trib. There are a couple of changes that would do this. I have not thought this through entirely, but here is a start
• Identify this inlet as a plugin.
• Option 1: presence of plugin.json ; name of plugin directory given in the JSON.
• Change server save code so that if inlet is a plugin then it gets written to that directory.

[Ian Johnson]

Please do submit pull requests :)

sorry for the delay, it was a lot to read but I do really appreciate your input and contributions!

i've done my best to answer inline below:

On Sun, Feb 15, 2015 at 10:08 PM, Mike Wolf <m...@mike-wolf.com> wrote:

Because I use Coffee mainly, I've done a bunch of experiments in the CoffeeContext

Because I haven't heard from you I did the changes in my own checkout.

I have some cleanup to do (probably another day) and can send you one or more pull requests

For my convenience it's best if I can send you just one or two pulls, but ideally there should be many and smaller. That's extra work for me, but I will do that if you want it.

Here's the stuff I've been working on. 

Please comment back.

Glad to hear from you.

Mike

1. I fixed a bug that comes up when you self-reference the editor and it runs before the editor has been assigned. I return from CoffeeContext if no editor I Assume that this same thing should be done for JSContext. 
• Comment? 

sounds reasonable. there could definitely be bugs. 

1. Stepping through the code in the debugger it appears that the .exec function is called several times before plugins are loaded. 
• What is the best way to ensure no execution until everything is loaded?
  

this is something i'd like to fix, but to be honest the complexity always confused me. i'm not sure the right answer 

1. I 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.
   

sweet 

2. The call to clear all widgets was in the "onrender" callback. But that is nowhere in the code. I changed it to "pre:execute" 
• Will that work right? Or will there be a problem if there are two different contexts (say JS and CS) running?
• Should it be both "onrender" and "pre:execute"

i'm not actually sure these days. testing is how i would determine it 

1. I made a change so that CoffeeScript compile error message in the coffeescript 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. 
• May need to change the clear-widgets code to clear the error messages separately since they might appear on different lines
  
• Made the below changes in the course of making this change
• Plan to add CoffeeLint like you have done on JSLint
2. Experimental: Third argument (persist) added to console.logJack so you can have it add a line, rather than replace the current line
• Leave in or take out? No longer needed.
3. Added console.logHTML so I could write two lines as a unit with arbitrary innerHTML
• Added a log-html CSS class with different coloring (error-like, for now) and without the indent and ">"
• Can I remove the indent and ">" properties from the inline-console class CSS I don't think they add any value

sounds good 

1. Passing the context as a third parameter, like g and tributary to initialize function. This lets me access the context's state without having to make an explicit reference
   

nice 

2. If the word 'debugger' appears on its own line in the JS then I add sourceMap 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. 
• For now is this hack OK?
• 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. 

tributary is a giant experiment, lets keep experimenting :) 

1. When I ran into the bug (1 above) I tried to work around it by hacking the gist at github, but kept reloading the same thing. Finally, later on read the server code and saw it is caching gists.
• What about adding a new API function that clears the cache. Or does something already do this?
  

id be in favor of this. i can't remember what the logic is for clearing the cache 

1. My Dev cycle for working on tributary is pretty awful and I need to change it. Currently I switch to my editor window (Sublime) and make the change. Move to a console window and run make. Back to browser window and reload. I need to improve this. 
• Do you have something already working that is better? 
• If not, I'd propose to run one of the node packages that monitor files for changes, and then does stuff. I'd have it run jslint and the make and if successful signal the server to force a reload.

EJ was using livereload, i think using a node watching lib would be pretty cool 

• Later, would like to make changes so most of the time one just works in Tributary. The following is a first step:
1. Plugins would be built and maintained in Trib. There are a couple of changes that would do this. I have not thought this through entirely, but here is a start
• Identify this inlet as a plugin.
• Option 1: presence of plugin.json ; name of plugin directory given in the JSON.
• Change server save code so that if inlet is a plugin then it gets written to that directory.

i'd love to make plugins easier to write and share. was also thinking of how to do this with requirejs and having them loaded from some directory.

dont want to let just anybody write a plugin to the server, but dynamically loading them from gists/inlets is a nice idea.