AW: [ann] AEditor 0.10, folding added

Try out AEditor and tell me if AEditor works on your
machine. Please report if there is any problems.
Ideas + Suggestions for improvements is welcome :slight_smile:

http://raa.ruby-lang.org/list.rhtml?name=aeditor

No replies ?

they dont mean to ignore your post intentionally, but
you know, there is a really good editor distributed with ruby.

SciTe. That’s the reason why i haven’t tried AEd. I allready got
familiar with SciTe.

I would also interested in your opinion guys.
going to test AEditor now …

[snip]


Simon Strandgaard

  • Henon

Try out AEditor and tell me if AEditor works on your
machine. Please report if there is any problems.
Ideas + Suggestions for improvements is welcome :slight_smile:

http://raa.ruby-lang.org/list.rhtml?name=aeditor

No replies ?

until simon.too_many_answers?
wait
replies += 1
end

they dont mean to ignore your post intentionally, but
you know, there is a really good editor distributed with ruby.
SciTe. That’s the reason why i haven’t tried AEd. I allready got
familiar with SciTe.

Yes, SciTe is a decent editor. Hopefully one day AEditor can replace it.
Internally SciTe is using the rich-edit-widget, Scintilla.
Scintilla is unfortunatly written in C++ and has no unittesting.
Otherwise its quite nice.

FreeRIDE is using Scintilla as its editor-widget. I hope one day to
entirely replace Scintilla-widget with the AEditor-widget.

also IntelliJ-Idea has many nice features which I hope AEditor will get.


examples of its features [ripped from intelliJ’s feature list]:

  • rename method, The renaming functionality allows you to rename any
    package, class, method or variable and automatically finds and corrects
    all references to it.
  • Moving classes and packages with reference correction.
  • extract method, Select a block of code and invoke Extract Method to
    turn it into a method. It will automatically analyze the code to
    detect which variables of the original method must be passed to the
    extracted method as parameters.
  • etc… 30 refactoring operations …

If we had an IDE for Ruby with such features… wow.
I will do my best in order to create such refactoring tools for ruby.

I would also interested in your opinion guys.
going to test AEditor now …

Great… tell me what you think :slight_smile:

···

On Wed, 13 Aug 2003 02:56:48 +0900, Recheis Meinrad wrote:


Simon Strandgaard

Try out AEditor and tell me if AEditor works on your
machine. Please report if there is any problems.
Ideas + Suggestions for improvements is welcome :slight_smile:

http://raa.ruby-lang.org/list.rhtml?name=aeditor

No replies ?

until simon.too_many_answers?
wait
replies += 1
end

they dont mean to ignore your post intentionally, but
you know, there is a really good editor distributed with ruby.
SciTe. That’s the reason why i haven’t tried AEd. I allready got
familiar with SciTe.

Yes, SciTe is a decent editor. Hopefully one day AEditor can replace it.
Internally SciTe is using the rich-edit-widget, Scintilla.
Scintilla is unfortunatly written in C++ and has no unittesting.
Otherwise its quite nice.

FreeRIDE is using Scintilla as its editor-widget. I hope one day to
entirely replace Scintilla-widget with the AEditor-widget.

I don’t currently have the extra bandwidth to personally take a look AEditor
(maybe later). But I don’t want to be silent either. I like what you have
done very much. Your goals are very much in line with FreeRIDE’s goals and
would very much like to see someone plug it in to FreeRIDE as a replacement
for Scintilla.

Curt

···

On Wed, 13 Aug 2003 02:56:48 +0900, Recheis Meinrad wrote:

also IntelliJ-Idea has many nice features which I hope AEditor will get.
http://www.intellij.com/idea/
examples of its features [ripped from intelliJ’s feature list]:

  • rename method, The renaming functionality allows you to rename any
    package, class, method or variable and automatically finds and corrects
    all references to it.
  • Moving classes and packages with reference correction.
  • extract method, Select a block of code and invoke Extract Method to
    turn it into a method. It will automatically analyze the code to
    detect which variables of the original method must be passed to the
    extracted method as parameters.
  • etc… 30 refactoring operations …

If we had an IDE for Ruby with such features… wow.
I will do my best in order to create such refactoring tools for ruby.

I would also interested in your opinion guys.
going to test AEditor now …

Great… tell me what you think :slight_smile:


Simon Strandgaard

Hello Simon,

Tuesday, August 12, 2003, 10:44:49 PM, you wrote:

also IntelliJ-Idea has many nice features which I hope AEditor will get.
http://www.intellij.com/idea/
examples of its features [ripped from intelliJ's feature list]:
* rename method, The renaming functionality allows you to rename any
  package, class, method or variable and automatically finds and corrects
  all references to it.
* Moving classes and packages with reference correction.
* extract method, Select a block of code and invoke Extract Method to
  turn it into a method. It will automatically analyze the code to
  detect which variables of the original method must be passed to the
  extracted method as parameters.
* etc.. 30 refactoring operations ..

If we had an IDE for Ruby with such features... wow.
I will do my best in order to create such refactoring tools for ruby.

Have you ever spend more then a few minutes to think about the
problems with refactoring in script languages and especially with
ruby ?

I guess you didn't.

The fexibility of languages like ruby makes it impossible to ever
write something like intellij. And it is not a parser problem. I can
write a full ruby parser in a weekend, but this would give me no clue
about the behaviour.

···

--
Best regards,
Lothar mailto:mailinglists@scriptolutions.com

Please do. We need a nice Ruby-based Ruby parser. Can we expect it by
next Monday?

:wink:

···

On Thu, 14 Aug 2003, Lothar Scholz wrote:

I can write a full ruby parser in a weekend, but this would give me no clue
about the behaviour.

If we had an IDE for Ruby with such features… wow.
I will do my best in order to create such refactoring tools for ruby.

Have you ever spend more then a few minutes to think about the
problems with refactoring in script languages and especially with
ruby ?

I guess you didn’t.

The fexibility of languages like ruby makes it impossible to ever
write something like intellij. And it is not a parser problem. I can
write a full ruby parser in a weekend, but this would give me no clue
about the behaviour.

Well, there are certainly problems with automatic
refactoring in dynamic languages.

But I think it is not pointless to try to write
refactoring tools. They are potentially of much
usefulness, even though they will always be
imperfect.

Hal

···

----- Original Message -----
From: “Lothar Scholz” mailinglists@scriptolutions.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org;
0bz63fz3m1qt3001@sneakemail.com
Cc: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Wednesday, August 13, 2003 1:03 PM
Subject: Re: AW: [ann] AEditor 0.10, folding added


Hal Fulton
hal9000@hypermetrics.com

Lothar Scholz wrote:

Hello Simon,

Tuesday, August 12, 2003, 10:44:49 PM, you wrote:

also IntelliJ-Idea has many nice features which I hope
AEditor will get.
http://www.intellij.com/idea/
examples of its features [ripped from intelliJ’s feature list]:

  • rename method, The renaming functionality allows you to rename any
    package, class, method or variable and automatically finds
    and corrects
    all references to it.
  • Moving classes and packages with reference correction.
  • extract method, Select a block of code and invoke Extract Method to
    turn it into a method. It will automatically analyze the code to
    detect which variables of the original method must be passed to the
    extracted method as parameters.
  • etc… 30 refactoring operations …

If we had an IDE for Ruby with such features… wow.
I will do my best in order to create such refactoring tools for ruby.

Have you ever spend more then a few minutes to think about the
problems with refactoring in script languages and especially with
ruby ?

I guess you didn’t.

The fexibility of languages like ruby makes it impossible to ever
write something like intellij. And it is not a parser problem. I can
write a full ruby parser in a weekend, but this would give me no clue
about the behaviour.

The problem is harder in a dynamically typed language like Ruby, but not
impossible. You can’t take it quite as far as you can in a strongly typed
language like Java, but you can implement a surprising amount of
functionality. You only need to look as far as the existing Smalltalk
refactoring tools to see just what can be done.

Curt

Hello Simon,

Tuesday, August 12, 2003, 10:44:49 PM, you wrote:

also IntelliJ-Idea has many nice features which I hope AEditor will get.
http://www.intellij.com/idea/
[snip]

  • etc… 30 refactoring operations …

Have you ever spend more then a few minutes to think about the
problems with refactoring in script languages and especially with
ruby ?

I guess you didn’t.

I have thought about it for more than 5 minutes, but not done any deep
analizis of what it would take. I agree with you that there is problems
with dynamic-typed languages.

Is there anyone who has done some analizis of what such refactoring-tool
exactly will require ? a ruby-in-ruby parser ?

The fexibility of languages like ruby makes it impossible to ever
write something like intellij. And it is not a parser problem. I can
write a full ruby parser in a weekend, but this would give me no clue
about the behaviour.

OK, also I look forward to a ruby-in-ruby parser on next monday :slight_smile:

···

On Thu, 14 Aug 2003 04:03:51 +0900, Lothar Scholz wrote:


Simon Strandgaard

This is an interesting assertion considering that the original
refactoring browser was written for Smalltalk which certainly is no
slouch when it comes to flexibility. So I would guess that a number of
refactorings would be possible, certainly enough to be useful.

I can see certain refactorings being more difficult in a Duck Typed
language, e.g. renaming a method (how do you if this use of a method
is one to be changed).

Here’s a question to folks that have used both the Smalltalk refactoring
browser and one of the Java IDEs (e.g. IntelliJ or Eclipse): In what
ways did refactoring support differ between the two languages?

···

On Wed, 2003-08-13 at 14:03, Lothar Scholz wrote:

Have you ever spend more then a few minutes to think about the
problems with refactoring in script languages and especially with
ruby ?

I guess you didn’t.

The fexibility of languages like ruby makes it impossible to ever
write something like intellij. And it is not a parser problem. I can
write a full ruby parser in a weekend, but this would give me no clue
about the behaviour.


– Jim Weirich jweirich@one.net http://onestepback.org

“Beware of bugs in the above code; I have only proved it correct,
not tried it.” – Donald Knuth (in a memo to Peter van Emde Boas)

I will add a lame “me too” to that :wink:

Actually, I would be happy with just a lexer.

···

On Thu, Aug 14, 2003 at 03:08:03AM +0900, Chad Fowler wrote:

On Thu, 14 Aug 2003, Lothar Scholz wrote:

I can write a full ruby parser in a weekend, but this would give me no clue
about the behaviour.

Please do. We need a nice Ruby-based Ruby parser. Can we expect it by
next Monday?


_ _

__ __ | | ___ _ __ ___ __ _ _ __
’_ \ / | __/ __| '_ _ \ / ` | ’ \
) | (| | |
__ \ | | | | | (| | | | |
.__/ _,
|_|/| || ||_,|| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

Never trust an operating system you don’t have sources for. :wink:
– Unknown source

A difference between smalltalk and ruby…smalltalk is image based
whereas ruby is file based. The order you load files determines the
replacement of capability. This is going to have to be a factor in
whoever works to build ruby refactoring capability.

BTW: Although refactoring is important, so is generating code. That
could be done quite quickly yet yield nice payoff.

-rich

-rich

···

On Wednesday, August 13, 2003, at 06:58 PM, Jim Weirich wrote:

I can see certain refactorings being more difficult in a Duck Typed
language, e.g. renaming a method (how do you if this use of a method
is one to be changed).

Here’s a question to folks that have used both the Smalltalk
refactoring
browser and one of the Java IDEs (e.g. IntelliJ or Eclipse): In what
ways did refactoring support differ between the two languages?

Hello Simon,

Tuesday, August 12, 2003, 10:44:49 PM, you wrote:

Have you ever spend more then a few minutes to think about the
problems with refactoring in script languages and especially with
ruby ?

I guess you didn’t.

I have thought about it for more than 5 minutes, but not done any deep
analizis of what it would take. I agree with you that there is
problems with dynamic-typed languages.

Is there anyone who has done some analizis of what such
refactoring-tool exactly will require ? a ruby-in-ruby parser ?

The parser would be the easy part (probably).

Once you have the parser, consider renaming the method Foo#bar to
Foo#foo():

------8<-----
class Foo; def bob; end; end
class Bar; def bob; end; def foo; Foo.new; end; end

a = Foo.new
b = Bar.new
a, b = b, a

a.bob
b.bob
------8<-----

So far, it would be relatively simple to track variable assignment and
work out which variables are instances of Foo and then rename references
from Foo#bob() to Foo#foo

------8<-----
def bar(*args)
args.each do |obj|
obj.bob if obj.respond_to?(:bob)
end
end

bar(a, b, a.bob)
------8<-----

Here it becomes somewhat more difficult - it might be fair to
assume that in most cases the author wishes to rename Foo#bob so that it
isn’t called by bar(), but not always. And how should the refactoring
agent change the code if it isn’t?

def bar(*args)
args.each do |obj|
if obj.kind_of?(Foo)
obj.foo if obj.respond_to?(:foo)
else
obj.bob if obj.respond_to?(:bob)
end
end
end

??

------8<-----
a.foo.bob
------8<-----

And although in the code above, you could determine fairly easily what
type of object will be returned by Bar#foo(), it would be very easy to
think of situations where it wouldn’t be easy and, in the case of
compiled C extensions, not possible.

------8<----
str = ‘BOB’.downcase


b.method(str).to_proc
b.send(str.intern)
------8<----

I won’t comment. Or mention eval. Or instance_eval. Or module_eval.
Or subclasses which may or may not define the same method which may or
may not call super().

AIUI, refactoring is supposed not to change the behaviour of the code:
And without creating either a ruby simulator which could run a ruby
script and determine every single variable which could possibly be an
instance of Foo, and then take into account code which is dynamically
generated from external sources, e.g. DRb, marshalled data, class and
function names derived from a database/other programs. And if you end
up treating almost every variable and function return as a potential
instance of Foo then do you have to refactor the every possible
reference to Foo#bob with an if obj.kind_of?(Foo) … else … end?

So in answer to your question, in order to refactor Ruby code it’s
probably not possible without a divining rod, some form of mind reading
and lashings of good luck. And even if you manage a no-side-effects
refactor, will it really acheive the end of making the script more
legible to the programmer?

The problem could be partially solved by designing strict rules for
writing a style of Ruby which could be refactored in well defined ways,
but I don’t think that it would be feasible to do for an otherwise
unknown Ruby script.

If, for example, all code was to be duck typed, so that the behaviour of
instance method #foo should be the same in Foo as in Bar, then renaming
would be simpler, because you would normally either be renaming all
references a particular instance method name (regardless of the object
class) or simply renaming the method definition within the class
definition because it no longer conforms to the behaviour specified for
the name. Even so it would require checking for literals which match
the function name, whether symbols or strings or the contents of arrays
so that you have a chance of catching most obj.send(sym). And the
problem with changing those is then calculating the side effects.

Of course, I have only considered renaming a method which is just one
(relatively simple?) refactoring operation.

The fexibility of languages like ruby makes it impossible to ever
write something like intellij. And it is not a parser problem. I can
write a full ruby parser in a weekend, but this would give me no
clue about the behaviour.

OK, also I look forward to a ruby-in-ruby parser on next monday :slight_smile:

Even if he did, it would only be of real use to AEditor for syntax
highlighting and, possibly, automatic recognition of possible folds.

And it shouldn’t be hard to do - with StringScanner it should be fairly
straight forward. Of course it depends what you mean by a ‘parser’. If
you want a function that returns an array of tokens, it shouldn’t take
long. If you want a ruby-in-ruby interpreter, it would take a bit
longer… :slight_smile:

TTFN,

Geoff.

···

On Thu, Aug 14, 2003 at 05:27:58AM +0900, Simon Strandgaard wrote:

On Thu, 14 Aug 2003 04:03:51 +0900, Lothar Scholz wrote:

talking about refactoring…

It would be really nice with a tool which can tell
which code-lines in a project, which is untested.
Then you can easily identify weak parts which maybe
will need better unittesting.
I think this decipline is called ‘path testing’.
Does such tool for ruby exist ?

BTW: If our ruby-refactoring tool are connected with
the unittests, then it maybe will become easier to
identify which places to rename ? needs thinking.

···


Simon Strandgaard

Hello Geoff,

Thursday, August 14, 2003, 10:52:18 AM, you wrote:

The parser would be the easy part (probably).

Right. Stealing it from the ruby source code does not take a long time.
The biggest problem is that no one seems to be interested in
maintaining a precise BNF grammer of the language. With the grammer and bison
it shouldn’t take longer then a day.

Once you have the parser, consider renaming the method Foo#bar to
Foo#foo():

------8<-----
class Foo; def bob; end; end
class Bar; def bob; end; def foo; Foo.new; end; end

a = Foo.new
b = Bar.new
a, b = b, a

a.bob
b.bob
------8<-----

So far, it would be relatively simple to track variable assignment and
work out which variables are instances of Foo and then rename references
from Foo#bob() to Foo#foo

tracking variable assignment becomes an O(exp n) problem if you must
follow all paths. So its really unuseable in real world code.

And although in the code above, you could determine fairly easily what
type of object will be returned by Bar#foo(), it would be very easy to
think of situations where it wouldn’t be easy and, in the case of
compiled C extensions, not possible.

I was thinking a while about tracking the types of arguments and
results during the runtime of testcases. But this was only to support
more exact tooltips (code insight). It is very obvious to see that
tracking information at runtime can only give a partial set of
information.

AIUI, refactoring is supposed not to change the behaviour of the code:

Right, i think that when you offer refactoring, a lot of programmers become
more lazy in the design phase. And this is bad, because refactoring in
Ruby/Python/PHP/Perl can’t do the same as refactoring in java. They will run
into problems very soon and much sooner if the projects are growing and
become multi person projects where everyone has it’s own coding style.

The problem could be partially solved by designing strict rules for
writing a style of Ruby which could be refactored in well defined ways,
but I don’t think that it would be feasible to do for an otherwise
unknown Ruby script.

And this would eliminate the elegance of some ruby solutions and
eliminate quite a few reasons to use ruby. So it’s not a good
decision.

···


Best regards,
Lothar mailto:mailinglists@scriptolutions.com

That’s intriguing. Do you mean that Ruby could be used at slightly higher
level so the descriptions are less sensitive to common re-factorings? Would
you then leave the re-factorings to the ‘code-generation’ functionality?

Cheers …

···

“Richard Kilmer” rich@infoether.com wrote:

BTW: Although refactoring is important, so is generating code. That
could be done quite quickly yet yield nice payoff.

Search for “zen” on RAA. Look for something like zenspider, which I
haven’t used but have heard good things.

Gavin

···

On Friday, August 15, 2003, 5:10:25 AM, Simon wrote:

talking about refactoring…

It would be really nice with a tool which can tell
which code-lines in a project, which is untested.
Then you can easily identify weak parts which maybe
will need better unittesting.
I think this decipline is called ‘path testing’.
Does such tool for ruby exist ?

On Thu, 2003-08-14 at 07:36, Lothar Scholz wrote:> GY> So far, it would
be relatively simple to track variable assignment and

work out which variables are instances of Foo and then rename references
from Foo#bob() to Foo#foo

tracking variable assignment becomes an O(exp n) problem if you must
follow all paths. So its really unuseable in real world code.

SmartEiffel does this, and does it fast.

Still doesn’t solve the problem of dynamically loaded/generated code,
but should address most of the problem.

Right, i think that when you offer refactoring, a lot of programmers become
more lazy in the design phase. And this is bad, because refactoring in
Ruby/Python/PHP/Perl can’t do the same as refactoring in java. They will run
into problems very soon and much sooner if the projects are growing and
become multi person projects where everyone has it’s own coding style.

An interesting theory … but if you are saying undisciplined groups
will have problems, then that is true independently of whether
refactoring is availble or not. Hardly an argument against refactoring.

···


– Jim Weirich jweirich@one.net http://onestepback.org

“Beware of bugs in the above code; I have only proved it correct,
not tried it.” – Donald Knuth (in a memo to Peter van Emde Boas)

Go study the parse.y file in the Ruby distribution. The lexer is hand
written, and the parser is tightly bound to the Ruby runtime. If after
study, however, you think you could generate a precise BNF grammar from
it…please do…but I don’t think its that easy :wink:

-rich

···

On Thursday, August 14, 2003, at 07:36 AM, Lothar Scholz wrote:

Right. Stealing it from the ruby source code does not take a long time.
The biggest problem is that no one seems to be interested in
maintaining a precise BNF grammer of the language. With the grammer
and bison
it shouldn’t take longer then a day.

Well, you already do dynamic code generation in the language itself:

class Foo
attr_accessor :bar
# the attr_accessor method generates the following code (with eval):
def bar=(value)
@bar = value
end
def bar
@bar
end

That is powerful…but not what I am talking about.

Here is a simple example:

class Foo
def intialize(x,y,z)

at this point I press a magic generator key and this code appears:

 @x = x
 @y = y
 @z = z

and then displays a dialog to chose which of these you want

externalized

(if any) and inserts (above def initialize…) something like…

attr_accessor :x,:y
attr_reader :z

and then I can continue with my coding…

Ruby is already fast to code in, but there is still common things that
could be automated…that’s all.

-rich

···

On Thursday, August 14, 2003, at 11:09 AM, Its Me wrote:

“Richard Kilmer” rich@infoether.com wrote:

BTW: Although refactoring is important, so is generating code. That
could be done quite quickly yet yield nice payoff.

That’s intriguing. Do you mean that Ruby could be used at slightly
higher
level so the descriptions are less sensitive to common re-factorings?
Would
you then leave the re-factorings to the 'code-generation’
functionality?

searching for ‘zen’ yields 3 results
http://raa.ruby-lang.org/search.rhtml?search=zen
zenweb seems to be a collection of web-formatting tools.

unfortunatly nothing relates to path-testing.
I am interested in trying out such tool; does it exist ?

···

On Sat, 16 Aug 2003 13:19:38 +0900, Gavin Sinclair wrote:

On Friday, August 15, 2003, 5:10:25 AM, Simon wrote:

It would be really nice with a tool which can tell
which code-lines in a project, which is untested.
Then you can easily identify weak parts which maybe
will need better unittesting.
I think this decipline is called ‘path testing’.
Does such tool for ruby exist ?

Search for “zen” on RAA. Look for something like zenspider, which I
haven’t used but have heard good things.


Simon Strandgaard