Plugins

[mharris717]

So I've got a basic plugin system working. Very interested in using this code as a discussion point. I can squash it down later when we're getting close to a merge.

Highlights:

• A plugin is just a normal Ruby class that optionally implements some methods and registers itself with LtRuby::Plugin.register.
• Plugins can hook in and do things at specified points. Right now the only one implemented is "connected completed."
• Plugins can handle messages from Light Table. I've moved the spec runner and project file code into plugins. The regular eval code could also be moved into a plugin.
• User can specify plugins to load with the (:lt.objs.langs.ruby/use-plugin NAME) user behavior. As of now this just calls require NAME.
• Anyone can make a plugin, package it as a regular gem (or use a gem released by someone else), and include it with the user behavior. The plugin will be loaded and will be a first class citizen.

[existentialmutt]

sounds very nifty! That could make some ideas I've had more clean to
implement (e.g. connect to a remote debugger). I'll take a closer look
this evening and let you know.

~Rafe

On Tue, Feb 11, 2014 at 3:48 PM, mharris717 notifications@github.51.alwrote:

So I've got a basic plugin system working. Very interested in using this
code as a discussion point. I can squash it down later when we're getting
close to a merge.

Highlights:

A plugin is just a normal Ruby class that optionally implements some
methods and registers itself with LtRuby::Plugin.register.

Plugins can hook in and do things at specified points. Right now the
only one implemented is "connected completed."

Plugins can handle messages from Light Table. I've moved the spec
runner and project file code into plugins. The regular eval code could also
be moved into a plugin.

User can specify plugins to load with the
(:lt.objs.langs.ruby/use-plugin NAME) user behavior. As of now this just
calls require NAME.

Anyone can make a plugin, package it as a regular gem (or use a gem
released by someone else), and include it with the user behavior. The
plugin will be loaded and will be a first class citizen.

---

You can merge this Pull Request by running

git pull https://github.com/mharris717/lt-ruby plugins

Or view, comment on, or merge it at:

#28
Commit Summary

• Plugin behavior works
• bare bones plugin works
• Some cleanup
• more cleanup
• more cleanup

File Changes

• M .gitignorehttps://github.com/Plugins #28/files#diff-0(2)
• M rb-src/handle_specs.rbhttps://github.com/Plugins #28/files#diff-1(13)
• M rb-src/lt_client.rbhttps://github.com/Plugins #28/files#diff-2(44)
• M rb-src/lt_client_runner.shhttps://github.com/Plugins #28/files#diff-3(4)
• A rb-src/plugin.rbhttps://github.com/Plugins #28/files#diff-4(54)
• A rb-src/project_file.rbhttps://github.com/Plugins #28/files#diff-5(16)
• M rb-src/spec/client_spec.rbhttps://github.com/Plugins #28/files#diff-6(9)
• M ruby instarepl_compiled.jshttps://github.com/Plugins #28/files#diff-7(255)
• M ruby instarepl_compiled.js.maphttps://github.com/Plugins #28/files#diff-8(61)
• M src/lt/plugins/ruby.cljshttps://github.com/Plugins #28/files#diff-9(23)

Patch Links:

• https://github.com/existentialmutt/lt-ruby/pull/28.patch
• https://github.com/existentialmutt/lt-ruby/pull/28.diff

Reply to this email directly or view it on GitHubhttps://github.com//pull/28
.

[existentialmutt]

...further thoughts

On Tue, Feb 11, 2014 at 3:57 PM, Rafe Rosen rafe.rosen@gmail.com wrote:

sounds very nifty! That could make some ideas I've had more clean to
implement (e.g. connect to a remote debugger). I'll take a closer look
this evening and let you know.

~Rafe

On Tue, Feb 11, 2014 at 3:48 PM, mharris717 notifications@github.51.alwrote:

So I've got a basic plugin system working. Very interested in using this
code as a discussion point. I can squash it down later when we're getting
close to a merge.

Highlights:

A plugin is just a normal Ruby class that optionally implements some
methods and registers itself with LtRuby::Plugin.register.

Plugins can hook in and do things at specified points. Right now the
only one implemented is "connected completed."

Plugins can handle messages from Light Table. I've moved the spec
runner and project file code into plugins. The regular eval code could also
be moved into a plugin.

User can specify plugins to load with the
(:lt.objs.langs.ruby/use-plugin NAME) user behavior. As of now this just
calls require NAME.

Anyone can make a plugin, package it as a regular gem (or use a gem
released by someone else), and include it with the user behavior. The
plugin will be loaded and will be a first class citizen.

---

You can merge this Pull Request by running

git pull https://github.com/mharris717/lt-ruby plugins

Or view, comment on, or merge it at:

#28
Commit Summary

• Plugin behavior works
• bare bones plugin works
• Some cleanup
• more cleanup
• more cleanup

File Changes

• M .gitignorehttps://github.com/Plugins #28/files#diff-0(2)
• M rb-src/handle_specs.rbhttps://github.com/Plugins #28/files#diff-1(13)
• M rb-src/lt_client.rbhttps://github.com/Plugins #28/files#diff-2(44)
• M rb-src/lt_client_runner.shhttps://github.com/Plugins #28/files#diff-3(4)
• A rb-src/plugin.rbhttps://github.com/Plugins #28/files#diff-4(54)
• A rb-src/project_file.rbhttps://github.com/Plugins #28/files#diff-5(16)
• M rb-src/spec/client_spec.rbhttps://github.com/Plugins #28/files#diff-6(9)
• M ruby instarepl_compiled.jshttps://github.com/Plugins #28/files#diff-7(255)
• M ruby instarepl_compiled.js.maphttps://github.com/Plugins #28/files#diff-8(61)
• M src/lt/plugins/ruby.cljshttps://github.com/Plugins #28/files#diff-9(23)

Patch Links:

• https://github.com/existentialmutt/lt-ruby/pull/28.patch
• https://github.com/existentialmutt/lt-ruby/pull/28.diff

Reply to this email directly or view it on GitHubhttps://github.com//pull/28
.

[mharris717]

A debugger was near the top of my list also. I was just taking a look at what was out there. Have you started implementing anything?

[existentialmutt]

just did some research. Current thinking is to start an rdebug -c or
remote-pry process and redirect standard input/output.

Are you finding any other good options?

On Tue, Feb 11, 2014 at 4:01 PM, mharris717 notifications@github.51.alwrote:

A debugger was near the top of my list also. I was just taking a look at
what was out there. Have you started implementing anything?

Reply to this email directly or view it on GitHubhttps://github.com//pull/28#issuecomment-34806310
.

[mharris717]

I'm trying to make sense of the options, and of what exactly ruby-debug-ide/debugger-xml does. Just need to get familiar.

[mharris717]

Any way you'd have time this week to get on Skype for a short period and go over the clojurescript code? I have a very tenuous grasp of it, but would be super helpful to get a quick runthrough.

[existentialmutt]

sure. Just sent you an email by way of the Light Table google group.

[mharris717]

Planning on writing a gem to give a pleasant debugger interface tomorrow

[mharris717]

I'm really bad at handling processes in Ruby, but I muddled through:

https://github.com/mharris717/rest_debug

[existentialmutt]

I really like what you've done here. In particular, I'd be interested in using this system to support multiple kinds of connections from light table that each have their own client process and mixture of plugins. For example, you could start a Rails Server from within light table by launching a client with the appropriate plugin. Or when you're in a spec file and hit eval the client that starts up loads handle_specs. If you did the same from a regular ruby file it would load handle_eval.

This would also allow us to package distinct functionality as separate Light Table plugins, which depend on a common ruby-plugin-running LT Plugin.

A couple thoughts related to that:

• Will users really want to specify plugins in user behaviors? I guess it depends on what kinds of plugins are available. The way I'm seeing this get used the connection that spawns the client process would come with a list of plugins to require, which gets added to the
• per our discussion earlier, we will probably eventually want to start having distinct commands instead of overloading editor.eval.ruby. Once we have that the "commands" array we send back to Light Table after connect should look at what the loaded ruby plugins support rather than a hardcoded "editor.eval.ruby" See lt_client.rb:55

[mharris717]

Sorry for delay. Agree with basically everything you wrote.

Not sure if users would want to specify plugins directly. Was thinking of a use case where somebody releases a ruby plugin that a user wants to use. User behaviors are one place you can do that. But there are other places.

Agree about the new commands. Ruby Plugins can say what new commands they support, the main ruby code can ask each plugins and send a full list.

Should we come up with a different name than "plugin?" It's appropriate, but also probably confusing, since there are already LT plugins. Best idea off the top of my head is Addon.

[existentialmutt]

Agree re: changing the name to avoid confusion with LT plugins. Addon sounds just fine to me.