[#4346] Segmentation fault — Andrew Walrond <andrew@...>
FYI, just got this random unexpected crash
On 01 Feb 2005, at 07:33, Andrew Walrond wrote:
[#4360] Adding lastlog info to etc — "Berger, Daniel" <Daniel.Berger@...>
Hi all,
[#4368] 'when (cond):' causes SyntaxError — "NAKAMURA, Hiroshi" <nakahiro@...>
Hi,
[#4385] add color_set support to curses.c — Paul Duncan <pabs@...>
I'm not sure why this is missing from the Curses binding, but the
[#4392] HTTP Basic authentication for open_uri — Kent Sibilev <ksibilev@...>
Can somebody apply the following patch for open_uri in order to enable
[#4402] BUG: Struct.new(:a?).instance_methods — "Cs. Henk" <csaba-ml@...>
Hi, getting an ArgumentError with "NULL pointer given" doesn't seem to
[#4403] Re: Unknown OS X 10.2 Socket constants (+script to generate) — Sam Roberts <sroberts@...>
Quoteing matz@ruby-lang.org, on Tue, Feb 08, 2005 at 01:21:18PM +0900:
[#4427] Re: windows socket connection freeze — ville.mattila@...
[#4432] curses + threads = non-blocking getch — William Morgan <wmorgan-ruby-core@...>
Hello experts,
In article <20050214231544.GE26414@masanjin.net>,
[#4439] Thread-safe Ruby Status? — Vincent Isambart <vincent.isambart@...>
Hello,
[#4448] add persistent history to irb — "David A. Black" <dblack@...>
Hi --
[#4453] bug in IRB with $_ matching a range of regexps — Ryan Davis <ryand-ruby@...>
> % ruby -v
[#4468] Re: Strange argc check in stable snapshot — "Berger, Daniel" <Daniel.Berger@...>
> -----Original Message-----
[#4475] Re: Strange argc check in stable snapshot — "Berger, Daniel" <Daniel.Berger@...>
> -----Original Message-----
[#4479] Requesting addition to IRB (configurable standard output) — Sascha Ebach <se@...>
Hello,
Quoting se@digitale-wertschoepfung.de, on Fri, Feb 25, 2005 at 01:22:34AM +0900:
On 24 Feb 2005, at 19:51, Sam Roberts wrote:
Quoting drbrain@segment7.net, on Sat, Feb 26, 2005 at 02:43:31AM +0900:
On 25 Feb 2005, at 16:03, Sam Roberts wrote:
Quoting drbrain@segment7.net, on Sat, Feb 26, 2005 at 10:24:52AM +0900:
On 25 Feb 2005, at 18:55, Sam Roberts wrote:
Quoting drbrain@segment7.net, on Sat, Feb 26, 2005 at 03:49:49PM +0900:
Re: Requesting addition to IRB (configurable standard output)
Quoting se@digitale-wertschoepfung.de, on Fri, Feb 25, 2005 at 01:22:34AM +0900:
> Hello,
>
> I was talking to Florian Gross on IRC about his Breakpoint library
> http://rubyforge.org/projects/ruby-breakpoint/ which I (and many others)
> use in Rails applications for testing and debbugging purposes.
>
> I often use it to see what is going on with my objects. Sometimes they
> are pretty big (filled with lots of data). The standard output of IRB
> looks like #inspect output.
>
> irb(main):006:0> [1,2,3].inspect
> => "[1, 2, 3]"
>
> This can be really noisy if the objects that are inspected have a lot of
> data in them (like a whole page of HTML).
>
> It would be nice if this were configurable. There already is an option
> --inspect for IRB. So what I am requesting is that one can define their
> own "inspector" like this.
How about irb uses #to_irb if it exists, then #inspect if it doesn't.
So, if you like to see pp output instead of inspect, put this in your
~/.irbrc:
module Kernel
def to_pp
s = PP.pp(self, '')
s.chomp!
s
end
alias_method :to_irb :to_pp
end
If you like yaml (go figure):
module Kernel
alias_method :to_irb :to_yaml
end
If you like yaml, but only for hashes:
class Hash
alias_method :to_irb :to_yaml
end
everything else will continue to use #inspect.
I don't think this kind of hacking requires a cmd line option, but a
hook to allow folks to do it in their irbrc might be nice.
Cheers,
Sam
> irb --inspect=y
> or
> irb --inspect=pretty_print_inspect
> or
> irb --inspect=some_selfmade_inspector
>
> irb --inspect would be equal to irb --inspect=inspect
>
> given irb --inspect=y output would look like this:
>
> $ irb -ryaml --inspect=y
> irb(main):002:0> [1,2,3]
> ---
> - 1
> - 2
> - 3
>
> Do you think this would be worthy addition to IRB? Florian suggested to
> ask on the ruby-core ML cause this is rather a feature that should be in
> IRB than in ruby-breakpoint.
>
> Thank you for considering
>
> Sascha Ebach
>
>