obviously that's non-optimal, though, because it won't automatically
load every time. I honestly don't know how irb works on Windows boxes,
I have one but the irb on it is built into FreeRide or something. you
can probably use those commands to get started, though.
···
On 1/21/07, bbiker <renard@nc.rr.com> wrote:
Giles Bowkett wrote:
> I have a theory about this.
>
> My theory is that newbies ask for an IDE because they don't understand irb.
>
> If you're a newbie and you want an IDE, my advice is to give it up
> entirely and instead learn irb.
>
> You can get syntax coloring in irb with Wirble, and if you're using
> Rails, which many many newbies are, script/console is a Rails extended
> version of irb, which is very very good.
>
Question: How do you use wirble with win32 machine?
The wirble documentation talks about .irbrc file which obviously I do
not have
You can't. Not because you can't have a .irbrc file (You just need to
specify a directory in the HOME environment variable, and put it
there).. but because Microsoft got rid of color support in the command
prompt.
You could disable color in wirble and make it work though, I suspect.
···
On 1/21/07, bbiker <renard@nc.rr.com> wrote:
Giles Bowkett wrote:
> I have a theory about this.
>
> My theory is that newbies ask for an IDE because they don't understand irb.
>
> If you're a newbie and you want an IDE, my advice is to give it up
> entirely and instead learn irb.
>
> You can get syntax coloring in irb with Wirble, and if you're using
> Rails, which many many newbies are, script/console is a Rails extended
> version of irb, which is very very good.
>
Question: How do you use wirble with win32 machine?
The wirble documentation talks about .irbrc file which obviously I do
not have
I'm willing to bet that most of them don't understand how to effectively
use a REPL loop, and that's fine if you look at it from their
perspective.
That's exactly right. I'm good using REPL for simple scripting, but I
can't think of a good way to use it for bigger things. Could you point
me (us) out some reading on how to use it for serious development?
There is also the familiarity aspects. People coming from a non-REPL
background often look at it and ask, "Ok, now how do I save my program?"
or "Do I really have to retype my last 30 lines to fix that little bug
in method foo?".
Those are the very first questions that come to my mind, indeed. What
are the answers?
On 1/21/07, Wilson Bilkovich <wilsonb@gmail.com> wrote:
On 1/21/07, bbiker <renard@nc.rr.com> wrote:
> Giles Bowkett wrote:
> > I have a theory about this.
> >
> > My theory is that newbies ask for an IDE because they don't understand
irb.
> >
> > If you're a newbie and you want an IDE, my advice is to give it up
> > entirely and instead learn irb.
> >
> > You can get syntax coloring in irb with Wirble, and if you're using
> > Rails, which many many newbies are, script/console is a Rails extended
> > version of irb, which is very very good.
> >
>
> Question: How do you use wirble with win32 machine?
> The wirble documentation talks about .irbrc file which obviously I do
> not have
>
> ruby 1.8.5 (2006-08-25) [i386-mswin32]
> irb 0.9.5(05/04/13)
>
You can't. Not because you can't have a .irbrc file (You just need to
specify a directory in the HOME environment variable, and put it
there).. but because Microsoft got rid of color support in the command
prompt.
You could disable color in wirble and make it work though, I suspect.
A big project is just a ton of little projects, once you chop it up. Test driven development is all about that, I think.
James Edward Gray II
···
On Jan 21, 2007, at 8:20 PM, Helder Ribeiro wrote:
Jonathan Allen wrote:
I'm willing to bet that most of them don't understand how to effectively
use a REPL loop, and that's fine if you look at it from their
perspective.
That's exactly right. I'm good using REPL for simple scripting, but I
can't think of a good way to use it for bigger things. Could you point
me (us) out some reading on how to use it for serious development?
A big project is just a ton of little projects, once you chop it up.
Test driven development is all about that, I think.
Yes, but sometimes you can't chop it up so fine-grained that you have
self-contained, one-lined commands (that's what I meant by
'scripting').
Say you write up a method and want to correct it, you have retype or
find through the history by pressing "Up" all the lines that "worked"
and re-entering them. You also can't just read them from a file either,
AFAIK (not smthg like an incomplete method code, for instance).
Conversely, it's not trivial to go through the lines that "worked" in
that awkward "Up"-key fashion, then select them and save them out to a
file.
Those are the questions Jonathan Allen pointed out, and I don't have
good answers for them.
Perhaps there's some different mode in irb where you can quickly
inspect the aggregated command history as in a regular editor and
choose to append selected lines out to a file? That'd be very helpful,
especially with the ability to load them back as if you had typed them
in yourself, which would allow for loading of incomplete blocks of
code.
···
On Jan 21, 2007, at 8:20 PM, Helder Ribeiro wrote:
That's exactly right. I'm good using REPL for simple scripting, but I
can't think of a good way to use it for bigger things. Could you point
me (us) out some reading on how to use it for serious development?
A big project is just a ton of little projects, once you chop it up. Test driven development is all about that, I think.
James Edward Gray II
Uh ... not really, for a number of reasons. To use the old saw about nine women not being able to produce a baby in one month, a baby is not a collection of small separately-developed pieces. A large software project is a complex adaptive system, interacting with numerous machines, users, creators and maintainers in many different ways. One distinguishing characteristic of complex adaptive systems is that they exhibit behavior that *can't* be explained or predicted by examining their components. Just like the baby, there are pieces you can remove that degrade their functioning, pieces like hair and toenails that return if removed (log files, for example ) and pieces you can't remove without destroying their functioning.
Irb-style "design-at-the-keyboard" doesn't scale beyond a small, "agile" project. I'm not sure test-driven development or continuous refactoring do, either, because nobody has ever to my knowledge had the budget to attempt it -- we're all too busy on the next "complex adaptive software project that's good enough". Irb is *part* of the tool set you need to work on a complex adaptive Ruby software project. I can't imagine working on such a project without irb. But if text-based tools are *all* I'm allowed to work with, I'd seriously question my relationship with management.
···
On Jan 21, 2007, at 8:20 PM, Helder Ribeiro wrote:
I am not a very experienced Ruby programmer, but what I find helps in that
regard is that I do my irb work in a kde konsole. It displays all the old
lines that I've entered (and results) with its "History" feature. I then
use Linux style copy (select then paste with middle mouse button) to grab the
lines I want, paste them into my editor, and edit out the stuff I don't want
(if I've copied more than I want).
Randy Kramer
···
On Monday 22 January 2007 06:48 am, Helder Ribeiro wrote:
Say you write up a method and want to correct it, you have retype or
find through the history by pressing "Up" all the lines that "worked"
and re-entering them. You also can't just read them from a file either,
AFAIK (not smthg like an incomplete method code, for instance).
Conversely, it's not trivial to go through the lines that "worked" in
that awkward "Up"-key fashion, then select them and save them out to a
file.
Those are the questions Jonathan Allen pointed out, and I don't have
good answers for them.
Perhaps there's some different mode in irb where you can quickly
inspect the aggregated command history as in a regular editor and
choose to append selected lines out to a file? That'd be very helpful,
especially with the ability to load them back as if you had typed them
in yourself, which would allow for loading of incomplete blocks of
code.
Yes, but sometimes you can't chop it up so fine-grained that you have
self-contained, one-lined commands (that's what I meant by
'scripting').
I think it's harder for some projects than others, but I'm not willing to go all the way to "can't".
Say you write up a method and want to correct it, you have retype or
find through the history by pressing "Up" all the lines that "worked"
and re-entering them. You also can't just read them from a file either,
AFAIK (not smthg like an incomplete method code, for instance).
Conversely, it's not trivial to go through the lines that "worked" in
that awkward "Up"-key fashion, then select them and save them out to a
file.
Here are some ideas:
>> def test
>> puts "This line is OK."
>> puts "So is this one."
>> Object.new.no_such_method # Oops!
>> end
=> nil
>> test
This line is OK.
So is this one.
NoMethodError: undefined method `no_such_method' for #<Object:0x102f9ac>
from (irb):4:in `test'
from (irb):6
>> h 6
[0758] def test
[0759] puts "This line is OK."
[0760] puts "So is this one."
[0761] Object.new.no_such_method # Oops!
[0762] end
[0763] test
[0764] h 6
=> nil
>> get_lines(758..760) << "puts 'Now this is better.'" << "end"
=> ["def test", " puts "This line is OK."", " puts "So is this one."", "puts 'Now this is better.'", "end"]
>> eval((get_lines(758..760) << "puts 'Now this is better.'" << "end").join("\n"))
=> nil
>> test
This line is OK.
So is this one.
Now this is better.
=> nil
You can also write to a file:
>> hw "test_method.rb", 758..760
=> nil
>> File.read("test_method.rb")
=> "def test\n puts "This line is OK."\n puts "So is this one."\n"
>> File.open("test_method.rb", "a") { |f| f << " puts 'Fixed in the file.'\nend\n" }
=> #<File:test_method.rb (closed)>
>> File.read("test_method.rb")=> "def test\n puts "This line is OK."\n puts "So is this one."\n puts 'Fixed in the file.'\nend\n"
>> load "test_method.rb"
=> true
>> test
This line is OK.
So is this one.
Fixed in the file.
=> nil
On Jan 22, 2007, at 8:59 AM, M. Edward (Ed) Borasky wrote:
Irb-style "design-at-the-keyboard" doesn't scale beyond a small, "agile" project. I'm not sure test-driven development or continuous refactoring do, either, because nobody has ever to my knowledge had the budget to attempt it
Irb-style "design-at-the-keyboard" doesn't scale beyond a small, "agile" project. I'm not sure test-driven development or continuous refactoring do, either, because nobody has ever to my knowledge had the budget to attempt it
Thanks!! If I run out of queuing theory papers to buy, I might buy that one. However:
"the coordination and communication grows exponentially with the number of individual developers and sites. "
That's not correct, either. The formula *involves* exponentials, but the communication and coordination does not grow exponentially -- nothing large could be built if it did. I have the formulas somewhere; if I can find them, I'll post them here.
···
On Jan 22, 2007, at 8:59 AM, M. Edward (Ed) Borasky wrote:
Hey, great idea! I'm so used to the default mode using bash that I had
never noticed I could use irb from *inside* konsole. I always ran it
from bash. I'll try that out see how it works!
Thanks a lot!
Helder Ribeiro
···
On Jan 22, 11:16 am, Randy Kramer <rhkra...@gmail.com> wrote:
I am not a very experienced Ruby programmer, but what I find helps in that
regard is that I do my irb work in a kde konsole. It displays all the old
lines that I've entered (and results) with its "History" feature. I then
use Linux style copy (select then paste with middle mouse button) to grab the
lines I want, paste them into my editor, and edit out the stuff I don't want
(if I've copied more than I want).
Wow, this is awesome! The language is introspective and so is the REPL
=) I'll see how I get along with that. Thanks a lot!
Helder Ribeiro
···
On Jan 22, 11:55 am, James Edward Gray II <j...@grayproductions.net> wrote:
On Jan 22, 2007, at 5:48 AM,HelderRibeirowrote:
> Yes, but sometimes you can't chop it up so fine-grained that you have
> self-contained, one-lined commands (that's what I meant by
> 'scripting').I think it's harder for some projects than others, but I'm not
willing to go all the way to "can't".
> Say you write up a method and want to correct it, you have retype or
> find through the history by pressing "Up" all the lines that "worked"
> and re-entering them. You also can't just read them from a file
> either,
> AFAIK (not smthg like an incomplete method code, for instance).
> Conversely, it's not trivial to go through the lines that "worked" in
> that awkward "Up"-key fashion, then select them and save them out to a
> file.Here are some ideas:
>> def test
>> puts "This line is OK."
>> puts "So is this one."
>> Object.new.no_such_method # Oops!
>> end
=> nil
>> test
This line is OK.
So is this one.
NoMethodError: undefined method `no_such_method' for #<Object:0x102f9ac>
from (irb):4:in `test'
from (irb):6
>> h 6
[0758] def test
[0759] puts "This line is OK."
[0760] puts "So is this one."
[0761] Object.new.no_such_method # Oops!
[0762] end
[0763] test
[0764] h 6
=> nil
>> get_lines(758..760) << "puts 'Now this is better.'" << "end"
=> ["def test", " puts "This line is OK."", " puts "So is this
one."", "puts 'Now this is better.'", "end"]
>> eval((get_lines(758..760) << "puts 'Now this is better.'" <<
"end").join("\n"))
=> nil
>> test
This line is OK.
So is this one.
Now this is better.
=> nil
You can also write to a file:
>> hw "test_method.rb", 758..760
=> nil
>> File.read("test_method.rb")
=> "def test\n puts "This line is OK."\n puts "So is this one."\n"
>> File.open("test_method.rb", "a") { |f| f << " puts 'Fixed in the
file.'\nend\n" }
=> #<File:test_method.rb (closed)>
>> File.read("test_method.rb")=> "def test\n puts "This line is
OK."\n puts "So is this one."\n puts 'Fixed in the file.'\nend\n"
>> load "test_method.rb"
=> true
>> test
This line is OK.
So is this one.
Fixed in the file.
=> nil
On Tuesday 23 January 2007 06:20 pm, Helder Ribeiro wrote:
Hey, great idea! I'm so used to the default mode using bash that I had
never noticed I could use irb from *inside* konsole. I always ran it
from bash. I'll try that out see how it works!
) and pieces you can't remove without destroying their functioning.