[#6363] Re: rescue clause affecting IO loop behavior — ts <decoux@...>

>>>>> "D" == David Alan Black <dblack@candle.superlink.net> writes:

17 messages 2000/11/14
[#6367] Re: rescue clause affecting IO loop behavior — David Alan Black <dblack@...> 2000/11/14

Hello again --

[#6582] best way to interleaf arrays? — David Alan Black <dblack@...>

Hello --

15 messages 2000/11/26

[#6646] RE: Array Intersect (&) question — Aleksi Niemel<aleksi.niemela@...>

Ross asked something about widely known and largely ignored language (on

23 messages 2000/11/29
[#6652] RE: Array Intersect (&) question — rpmohn@... (Ross Mohn) 2000/11/29

aleksi.niemela@cinnober.com (Aleksi Niemel) wrote in

[#6723] Re: Array Intersect (&) question — Mathieu Bouchard <matju@...> 2000/12/01

> >Use a hash. Here's code to do both and more. It assumes that

[#6656] printing/accessing arrays and hashes — raja@... (Raja S.)

I'm coming to Ruby with a Python & Common Lisp background.

24 messages 2000/11/30

[ruby-talk:6105] Re: What would a Ruby browser look like?

From: "Conrad Schneiker/Austin/Contr/IBM" <schneik@...>
Date: 2000-11-07 06:17:16 UTC
List: ruby-talk #6105
Dave Thomas writes:

# A comment I heard several times at OOPSLA was that Ruby could take
# over the world if it had a good browser.

Then it's probably time for "there's a better way to do it" mode.

# So, I've been thinking about what a Ruby browser would look like.
# 
# I suspect everyone I talked with was anticipating something like a
# classic 4 pane Smalltalk browser. But would that really work?
# 
# How would we represent singleton classes, things like
# 
#    def a.fred
#      ...
#    end
# 
#    class <<bert
#      ...
#    end
# 
# or even simple things such as our code extending a system class
# 
#    class Object
#      def defaultsTo
#        self
#      end
#    end

(BTW: I vote for plain, simple, direct, brief, systematic ((WRT to 
"detect", "yield", etc.)), easy-to-remember "default". )

# I think that maybe we need a whole new way of looking at browser/IDE
# interfaces.

Well, one possible way to start is to consider what sorts of 
"macro-graphical-data-structures" might provide a good representation of 
Ruby programs, and what different types of attribute-selective "C.A.T. 
scans" would be useful for looking at it. (Hmm. How does Ruby "see" these 
things internally?)

Another possible way to start is to think how you might represent a Ruby 
program and the Ruby infrastructure as a big web site, and copy ideas used 
for GUI interfaces used to develop and manage such things. 

What sorts of features do advanced/modern programming environments for 
CLOS provide to deal with such things?
 
# Am I making this too difficult? 

Not if [y]our ultimate objective is to tame and render human-friendly 
various otherwise difficult cases that will commonly arise.

I think it might also be useful to ask, why do you want a browser anyway? 
What are the specific types of information it provides, what purposes does 
it serve in various cases, and so on? Are there some other methods 
(hyperlinks, colored code sections, or whatever) that could do this more 
directly? Maybe not, but you might still discover some better way to do 
classical browsers in the process of re-examining such things.

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)

In This Thread

Prev Next