Ideas about Smalltalk-like IDE for Ruby


#1

On 3/18/07, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote
in another thread proposing items for a Google SOC project.

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/


#2

Dave R. wrote:

stream-of-conscience
stepping that in total combine to a freedom to debug/process each
computer as my
‘save’ my program in tokenized
form and ‘save’ my variables separately too… to restart the whole
process where it left off…

Wow, another fan of BBX in this newsgroup! I have been programming in
BBX and Business Basic for over 25 years and find the interactive
features a big help when you can’t control the data. I love being able
to program a data conversion program to stop when it receives unplanned
for data and allow me to fix the data or program or both.


#3

Michael W. Ryder wrote:

Dave R. wrote:

Wow, another fan of BBX in this newsgroup! I have been programming in
BBX and Business Basic for over 25 years and find the interactive
features a big help when you can’t control the data. I love being able
to program a data conversion program to stop when it receives unplanned
for data and allow me to fix the data or program or both.
…cool…small world isn’t…dave


#4

It’s actually sort of possible to do this with Rails.

http://gyre.bitscribe.net/

(Disclaimer: I work for Bitscribe.)

The TextMate footnotes plugin can give you sort-of similar
functionality, and there are ObjectSpace hacks which can get you some
of the features of Smalltalk also. I realize that’s only halfway to
Smalltalk, at most, but the point is you can actually get some of
these benefits without having to construct an entire VM.


#5

Rick Denatale wrote:

On 3/18/07, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote
in another thread proposing items for a Google SOC project.

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.

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,

http://talklikeaduck.denhaven2.com/
…i still have to program in BASIS BASIC VPRO5…which is an IDE that
most of you have
have an already biased opinion because its BASIC … but it still beats
the pants off
ruby’s Breakpoint and IRB… i’ve actually perfected a technic i call
stream-of-conscience
program creation (yes, i’ve already planned what the forest of the
program will look like)
i can not only edit and run the same program in it’s own workspace
without ever having
to ‘save’ the program…and it’s just as dynamic interpretive as
Ruby…It uses (yikes) line
stmt numbers and old time non OO bnf fortran like syntac
processing…And it has some major
unique run-time debuging aids… like ‘goto’ to a specific stmt, escape
traps and single
stepping that in total combine to a freedom to debug/process each
program segment as it built.
I can always ‘clear’ out or ‘reset’ some or all of the variables and
start any or all of
program segments over with the ‘goto’ verb. As each program segment is
perfected i can then
combine their current values in each of the variables with the whole
program’s process while
that is still incomplete until all of the subsegments are built and done
with whole program.
This interactive testing is much like extreme programming but using the
computer as my
partner and is like Ruby unit testing but done manually using the
console commands ‘goto’
and ‘gosub’ to re-unit test each program segment. I don’t know how ruby
stores it’s parse
tree but in VPRO5 it’s stored with (appended to) the original stmt
(that’s ‘inline’
with the rest of the program) and the interpreter accepts
console mode command of ‘goto’ and ‘gosub’ along with the console cmds
of ‘clear’ and ‘reset’
Files and also be closed or opend at will too. At any time i can also
‘save’ my program in tokenized
form and ‘save’ my variables separately too… to restart the whole
process where it left off…


#6

On 3/19/07, Robert D. removed_email_address@domain.invalid wrote:

On 3/19/07, Rick DeNatale removed_email_address@domain.invalid wrote:

On 3/18/07, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote
in another thread proposing items for a Google SOC project.

As you might know I am very much interested in Smalltalk, but I have
never seen such a concise and good description of the “image”
paradigm.

Do you intend to put this on your BLOG?

I guess, if I get that round tuit I’m always looking for.


Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/


#7

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


#8

Wow. Glad this thread leapt back to life. Blogged, and added to my
list of things to check out in more detail.


#9

On Wed, Apr 11, 2007 at 07:05:06AM +0900, Mike A. wrote:

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.

That screenshot looks surprisingly like a Smalltalk IDE I’ve seen.


#10

On 3/19/07, Rick DeNatale removed_email_address@domain.invalid wrote:

On 3/18/07, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote
in another thread proposing items for a Google SOC project.

As you might know I am very much interested in Smalltalk, but I have
never seen such a concise and good description of the “image”
paradigm.

Do you intend to put this on your BLOG?

Cheers
Robert


#11

On Apr 11, 11:16 am, “Pedro Del G.” removed_email_address@domain.invalid
wrote:

I’ve wrote a GSoC proposal about this topic, but more focus in the
Smalltalk Browser than in the complete IDE. Finally, they marked as
ineligible, because i prefer to put all my “ruby money” in another
proposal.

Ruby code Browser [1] :http://theplana.wordpress.com/2007/04/10/gsoc-2007-ruby-code-browser/
Yes, that looks a nice and is just the sort of thing I had in mind.
You don’t say what toolkit you were intending to use, but if you could
have used the Qt/KDE apis via QtRuby/Korundum that would have made a
nice project for KDevelop 4. Unfortunately, the deadline for
submission has now passed. There is a good chance that a project for
adding/improving ruby parsing support to KDevelop 4 will be accepted,
and that will provide a foundation for building a visual development
environment.

The other 3 GSoC proposal : http://theplana.wordpress.com/tag/gsoc/
Good luck with this proposal!

– Richard


#12

I’ve wrote a GSoC proposal about this topic, but more focus in the
Smalltalk Browser than in the complete IDE. Finally, they marked as
ineligible, because i prefer to put all my “ruby money” in another
proposal.

Ruby code Browser [1] :
http://theplana.wordpress.com/2007/04/10/gsoc-2007-ruby-code-browser/

The other 3 GSoC proposal : http://theplana.wordpress.com/tag/gsoc/

All the critics are welcome.

Pedro Del G.

Email : removed_email_address@domain.invalid