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
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
Try out AEditor and tell me if AEditor works on your
machine. Please report if there is any problems.
Ideas + Suggestions for improvements is welcomeNo 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]:
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 
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 welcomeNo replies ?
until simon.too_many_answers?
wait
replies += 1
endthey 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.
IntelliJ IDEA ā the Leading Java and Kotlin IDE
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
ā
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.
IntelliJ IDEA ā the Leading Java and Kotlin IDE
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?
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.
IntelliJ IDEA ā the Leading Java and Kotlin IDE
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.
IntelliJ IDEA ā the Leading Java and Kotlin IDE
[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
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.
ā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
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.
ā 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
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ā¦
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#footracking 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.
ā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
-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)
@x = x
@y = y
@z = z
externalized
attr_accessor :x,:y
attr_reader :z
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