From: Mike Austin Date: 2007-04-11T07:05:06+09:00 Subject: Re: Ideas about Smalltalk-like IDE for Ruby This thread is getting older, but wanted to mention a project I've been working on called Inertia: http://www.mike-austin.com/inertia/index.html I just started working on it again lately, and looking for more ideas. Mike Rick DeNatale wrote: > On 3/18/07, richard.j.dale@gmail.com wrote > in another thread proposing items for a Google SOC project. > >> - Interactive visual irb. Like a Smalltalk environment I think ruby >> projects >> should be developed against an always running program. This makes >> code >> completion much easier as we can use ruby's runtime introspection >> instead of >> faking it with a combination of a static parser and guesswork. Can >> this be >> done if the language is text based, rather than image based like >> Smalltalk? >> How do we save state in between sessions? > > This is an intriguing idea. I'd love to have a Smalltalk-like IDE for > Ruby. I think that there are issues which make this an interesting > (i.e. difficult) task, so it might be worthwhile to discuss those > issues. > > For those who aren't familiar with Smalltalk, most Smalltalk > implementations combine run-time with the development environment. > That is to say that the development tools (browser/editors, debugger, > object inspectors, ...) are written in Smalltalk and run in the same > process as the code under development. This gives a great deal of > power to the ide, for example in Smalltalk, it's quite possible (and > common) to run your code, and when it brings up the debugger on an > exception or a breakpoint, edit the source code IN THE DEBUGGER, > maintaining as much ofthe execution state of the program as is > possible given the point on the execution stack of the change. Then > you can continue excution. I'll call this the 'always running' > feature. > > Another feature of most Smalltalk environments is that the running > state is persistent, When you leave the environment you can save the > memory image, and when you come back everything is as it was, > including instantiated objects, and the state of any threads which > were running/suspended at the time of image save. > > Another feature was that in traditional Smalltalk implementations, > source code was saved in the image, usually via offsets in the methods > to a 'changes' file. The system kept every edit of every method and > class definition, both to give an audit trail, and to allow recovery. > > I think that this is what Richard is hinting about when he talks about > an 'image-based' vs. 'file-based' language. I'd say that this is a > feature of the development environment rather than the language > per-se. It's really an issue of just how integrated the I in IDE is. > Most IDEs today are really just extensions of the 'emacs as shell' > idea, in that they are editors with the ability to invoke and interact > with other development tools to a greater of lesser extent. Smalltalk > ides tended to be integrated in that they subsumed the functions of > most if not all of those other tools. > > Now these features have both good and bad aspects. From a developer's > perspective. It gives great freedom and power. On the other hand it > poses issues for deployment. Tools were needed to strip the image of > the development tools if you wanted to ship a streamlined application. > > Another issue is/was that the source code system didn't play well with > other source control/configuration management tools. To a large > extent, the Smalltalk community went its own way on this one, > extending the change file/log approache with Smalltak based SC/SM > solutions to allow team development and tailoring Smalltalk > applications to a particular platform or environment. Probably the > most popular of these extensions was Envy/Developer from OTI which > kept source code in a repository. Rather than a check-out/check-in > model with optimistic locking a la CVC or SVN, Envy saved every edit > in the repository. The equivalent of checking out was to mark the > current set of edits in a developers image with a tag. > > I think that this 'file-based' vs. 'image-based' question can be > separated from the other issues. Of course if you want to be able to > save execution state in an image, it's probably important to be able > to keep track of what the current source code is whether it's stored > in files/a repository/or someplace else. > > But I digress. The real issues which interest me in starting this > thread are those which revolve around making an ide for Ruby with the > 'always running' features of the Smalltalk IDE. One issue I see here > is that Ruby as it stands right now doesn't really have a strong > enough introspection model of the execution state. For example, > walkbacks are strictly textual, whereas in Smalltalk the development > environment could obtain objects from the VM which represented the > execution stack and could be manipulated by tools like the debugger. > > Richard also brings up the idea of using run-time introspection as an > aid to features like code-completion. FIrst let me say that I can't > really recall much support for code-completion in Smalltalk > environments. What they typically provided was the ability to select > text in a browser and ask for an 'explanation' which told you as much > as could be determined about a variable, message, etc. You could also > do things like finding all senders of a message you were looking at > (what this really means is that you are looking at say Foo#bar it > would show you every method which invoked bar against any receiver), > or find all the implementors of the methods, or find the > senders/implementors of any methods sent by the methods being browsed, > etc. The problem of code completion in both Smalltalk and Ruby is > that if you are looking just at the source you really don't know all > the possible bindings of a variable to objects. If you are looking at > a stack frame in the debugger, you know the current binding so you > could do code completion based on the current object, but I don't see > that as a general solution. > > And of course Ruby ups the ante here because it's got a much more > dynamic notion of objects, including singleton methods, dynamically > created instance variables, modules ... > > Saving the state between runs likely requires support from the > interpreter/VM, it's really a matter of saving a relocatable memory > dump, then having the VM load and relocate the image on startup and > restore execution state from the relocated image. > > And I'd see this not as a simple 'interactive visual irb.' As useful > as irb is, it's really not a good basis for an IDE, I see it as a nice > eval-print-loop tool for trying out ideas, but an IDE needs lots more, > the function which irb brings to the table is pretty small in > comparison to the whole job that I'd think it would be better to start > from scratch here. > > Now, I'm not trying to throw cold water on this idea, I'm actually > quite interested in a discussion of how some of these issues could be > attacked so as to get a more dynamic IDE for Ruby.