IRB session to existing ruby process.

Re:IRB session to existing ruby process. by techscruggs on Wednesday January 25, 2012 @10:29AM (#3510015)

Two benefits I see (esp. w/ rails)

1) Quick console start. As rails developers, we spend way too much time waiting for consoles to start. This could save at least an hour out of my month.

2) Dynamically change production logging level. While their are ways to send signals to your process to control the logging level, this seems far more natural. You could easily open up an existing process change the logging level; finish your work; change it back.

Any other ideas for where the would be useful?

[ Parent | on HN ]

Re:IRB session to existing ruby process. by irahul on Wednesday January 25, 2012 @11:33AM (#3510350)

> 1) Quick console start. As rails developers, we spend way too much time waiting for consoles to start. This could save at least an hour out of my month.

Won't a better idea be to leave the console running?

[ Parent | on HN ]

Re:IRB session to existing ruby process. by techscruggs on Saturday January 28, 2012 @03:36PM (#3523164)

What about production consoles? And even with reload, what about those classes not in your autoload path?

[ Parent | on HN ]

Re:IRB session to existing ruby process. by Robin_Message on Wednesday January 25, 2012 @01:31PM (#3510993)

And then use reload!

[ Parent | on HN ]

Re:IRB session to existing ruby process. by techscruggs on Saturday January 28, 2012 @03:36PM (#3523165)

what about those classes not in your autoload path?

[ Parent | on HN ]

Re:IRB session to existing ruby process. by ileitch on Wednesday January 25, 2012 @10:49AM (#3510129)

Can be used to diagnose memory bloat issues by inspecting ObjectSpace.

[ Parent | on HN ]