On 3/18/07, email@example.com <firstname.lastname@example.org> 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/
on 2007-03-19 15:07
on 2007-03-19 15:44
Rick Denatale wrote: > On 3/18/07, email@example.com <firstname.lastname@example.org> 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...
on 2007-03-19 20:10
Dave Rose 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.
on 2007-03-19 21:02
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
on 2007-03-19 23:07
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.
on 2007-03-20 00:50
On 3/19/07, Rick DeNatale <email@example.com> wrote: > On 3/18/07, firstname.lastname@example.org <email@example.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
on 2007-03-20 15:31
On 3/19/07, Robert Dober <firstname.lastname@example.org> wrote: > On 3/19/07, Rick DeNatale <email@example.com> wrote: > > On 3/18/07, firstname.lastname@example.org <email@example.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.denhaven2.com/
on 2007-04-11 00:06
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
on 2007-04-11 01:31
Wow. Glad this thread leapt back to life. Blogged, and added to my list of things to check out in more detail.
on 2007-04-11 07:55
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/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.
on 2007-04-11 12:17
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  : http://theplana.wordpress.com/2007/04/10/gsoc-2007... The other 3 GSoC proposal : http://theplana.wordpress.com/tag/gsoc/ All the critics are welcome. -- ------------------------------------- Pedro Del Gallego Email : firstname.lastname@example.org
on 2007-04-11 13:55
On Apr 11, 11:16 am, "Pedro Del Gallego" <pedro.delgall...@gmail.com> 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  :http://theplana.wordpress.com/2007/04/10/gsoc-2007... 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