Asp Forum - Ideas about Smalltalk-like IDE for Ruby

Rick DeNatale

3/19/2007 2:06:00 PM

On 3/18/07, richard.j.dale@gmail.com <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.denh...

11 Answers

dave rose

3/19/2007 2:45:00 PM

Rick Denatale wrote:
> On 3/18/07, richard.j.dale@gmail.com <richard.j.dale@gmail.com> 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.denh...
...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...

--
Posted via http://www.ruby-....

Michael W. Ryder

3/19/2007 7:09:00 PM

Dave Rose wrote:
> Rick Denatale wrote:
>> On 3/18/07, richard.j.dale@gmail.com <richard.j.dale@gmail.com> 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.denh...
> ..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...
>

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.

dave rose

3/19/2007 8:03:00 PM

Michael W. Ryder wrote:
> Dave Rose 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

--
Posted via http://www.ruby-....

Giles Bowkett

3/19/2007 10:06:00 PM

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

http://gyre.bits...

(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.

--
Giles Bowkett
http://www.gilesg...
http://gilesbowkett.bl...
http://giles.t...

Robert Dober

3/19/2007 11:50:00 PM

On 3/19/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
> On 3/18/07, richard.j.dale@gmail.com <richard.j.dale@gmail.com> wrote
> in another thread proposing items for a Google SOC project.
> <snip>
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
> Rick DeNatale
>
> My blog on Ruby
> http://talklikeaduck.denh...
>
>

--
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw

Rick DeNatale

3/20/2007 2:31:00 PM

On 3/19/07, Robert Dober <robert.dober@gmail.com> wrote:
> On 3/19/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
> > On 3/18/07, richard.j.dale@gmail.com <richard.j.dale@gmail.com> wrote
> > in another thread proposing items for a Google SOC project.
> > <snip>
> 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.denh...

Clint

4/10/2007 10:02:00 PM

This thread is getting older, but wanted to mention a project I've been working
on called Inertia:

http://www.mike-austin.com/inertia/...

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

Giles Bowkett

4/10/2007 11:30:00 PM

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

On 4/10/07, Mike Austin <noone@nowhere.com> 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/...
>
> 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 <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.
>
>

--
Giles Bowkett
http://www.gilesg...
http://gilesbowkett.bl...
http://giles.t...

Chad Perrin

4/11/2007 5:56:00 AM

On Wed, Apr 11, 2007 at 07:05:06AM +0900, Mike Austin 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/...
>
> I just started working on it again lately, and looking for more ideas.

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

--
CCD CopyWrite Chad Perrin [ http://ccd.ap... ]
unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.

Pedro Del Gallego

4/11/2007 10:17:00 AM

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-cod...

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

All the critics are welcome.

--
-------------------------------------
Pedro Del Gallego

Email : pedro.delgallego@gmail.com

comp.lang.ruby

Ideas about Smalltalk-like IDE for Ruby

Rick DeNatale

dave rose

Michael W. Ryder

dave rose

Giles Bowkett

Robert Dober

Rick DeNatale

Clint

Giles Bowkett

Chad Perrin

Pedro Del Gallego

x Login to ForumsZone