From: Rick DeNatale Date: 2007-03-19T23:06:03+09:00 Subject: Ideas about Smalltalk-like IDE for Ruby 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. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/