Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2014/oss E1457 ags

2014-11-06T03:13:34Z

Gshah: /* Code Smells */

=Expertiza - Refactoring DynamicReviewMapping Controller and the ReportsController=

__TOC__

==Introduction==
It is time consuming to assess project work in a large classroom environment, and one of the best techniques to achieve this is to have students assist in this assessment. If each student is asked to assess a few (say, one to five) other students or student teams, the task requires a reasonable amount of effort; and that effort does not increase as the class gets larger. "''Expertiza is a system for managing all kinds of communication that is involved in assessment: double-blind communications between authors and reviewers, assessment of teammate contributions, evaluations by course staff, and surveys of students to assess the assignment and the
peer-review process.''" <ref>http://www.igi-global.com/book/monitoring-assessment-online-collaborative-environments/773&f=e-book</ref>
''"Expertiza project uses peer review to create reusable learning objects.''"<ref>http://expertiza.ncsu.edu/</ref> Students select from a list of tasks to be performed, with several students selecting each task. Then they prepare their work and submit it to an electronic peer-review system. The work is then reviewed by other students, who offer comments to help the submitters improve their work. The best submissions for each task are then selected for use in later courses. Expertiza gets students working together to improve others’ learning experiences. It helps them learn, by making them think through the lecture material and apply it to a real-world situation, just as they might do in an on-the-job situation. These learning objects can be improved iteratively; for example, the next year’s class can be presented with the examples developed by students the previous year, and asked to identify shortcomings and develop improved examples.<ref>http://scholar.google.com/scholar?q=%22Reusable+learning+objects+through+peer+review%3A+The+Expertiza+approach%22+%22The+Expertiza+platform+is+a+divide-and-conquer%22&btnG=&hl=en&as_sdt=0%2C34</ref> More information on Expertiza can be found [https://github.com/expertiza/expertiza here].

==Refactoring in Ruby==
Refactoring helps to<ref>http://www.refactoringinruby.com/</ref>
*Understand what led to poor code design
*Fix code which is difficult to understand
*Express each idea “once and only once”
*Recognize missing or inadequately formed classes
*Simplify overly complex relationships between classes
*Achieve the right balance of responsibilities among objects
*Make code easier to test and more maintainable

===Code Smells===
We identified the following categories of code smells in the helper module:

*Lengthy Definitions: These are the methods that have too many responsibilities and collaborators. As a result of which, their overall length has grown too long reducing the maintainability and readability.

*Duplicated Code: These are those pieces of code that does almost the same functionality of some other piece of code leading to a bad design style. They are usually too error prone since not everyone identifies all the code responsible for the same task and does the changes whenever the need arises.

*Bad method names: A good method name is expected to adhere to the Ruby style and design style guidelines. It is expected to convey a reasonable amount of responsibilities handled. A good method name in combination with good practices should resemble a user story.

*Used and unnecessary methods: These are those methods that were useful when the code was first developed. But, they lost their functionality as the code got updated and new functionalities were added or existing ones were modified.

===Refactoring Techniques===
There are many documented refactoring techniques, and a few common ones are below.<ref>http://www.integralist.co.uk/posts/refactoring-techniques/</ref>
*'''Rename Method''': Renaming identifiers can reduce the need for code comments and nearly always helps to promote greater clarity.
*'''Introduce Explaining Variable''': So here is a technique specifically based around the premise of renaming.
For example:
<pre>
unless "This is a String with some CAPS".scan(/([A-Z])/).empty?
puts "capitalised text was found"
end
</pre>
Should be:
<pre>
caps_not_found = "This is a String with some CAPS".scan(/([A-Z])/).empty?

unless caps_not_found
puts "capitalised text was found"
end
</pre>

*'''Extract Method''': It consists of breaking up long methods by shifting overly complex chunks of code into new methods which have very descriptive identifiers.
For example:
<pre>
class Foo
attr_reader :bar

def initialize bar
@bar = bar
end

def do_something
puts "my baz" # notice this is duplication
puts bar
end

def do_something_else
puts "my baz" # notice this is duplication
puts "Something else"
puts bar
end
end
</pre>

Becomes:
<pre>
class Foo
attr_reader :bar

def initialize bar
@bar = bar
end

def do_something
baz
puts bar
end

def do_something_else
baz
puts "Something else"
puts bar
end

def baz
puts "my baz"
end
end
</pre>

*'''Inline Method''': Sometimes you want the opposite of the Extract Method technique. Imagine a method exists whose content is already simple and clear, and whose identifier adds no extra benefit. So to fix this problem we'll convert the method invocation into an inlined piece of code.

*'''Pull Up Method''': When you have duplicated code across two separate classes then the best refactoring technique to implement is to pull that duplicate code up into a super class so we DRY (Don't Repeat Yourself) out the code and allow it to be used in multiple places without duplication (meaning changes in future only have to happen in one place).

For example:
<pre>
class Person
attr_reader :first_name, :last_name

def initialize first_name, last_name
@first_name = first_name
@last_name = last_name
end

end

class MalePerson < Person
# This is duplicated in the `FemalePerson` class
def full_name
first_name + " " + last_name
end

def gender
"M"
end
end

class FemalePerson < Person
# This is duplicated in the `MalePerson` class
def full_name
first_name + " " + last_name
end

def gender
"F"
end
end
</pre>
Becomes:
<pre>
class Person
attr_reader :first_name, :last_name

def initialize first_name, last_name
@first_name = first_name
@last_name = last_name
end

def full_name
first_name + " " + last_name
end
end

class MalePerson < Person
def gender
"M"
end
end

class FemalePerson < Person
def gender
"F"
end
end
</pre>

*'''Introduce Named Parameter''':When method arguments are unclear then convert them into named parameters so they become clearer (and easier to remember).

==Project Description==

We were supposed to refactor two controllers, the ReportsController and the DynamicReviewMapping Controller. The ReportsController was thought to be generating reports for students, showing all their scores in a single page. The DynamicReviewMapping Controller is actually a helper to the ReviewMapping controller. The review mapping controller maps reviews to each user. Currently, there are two ways to assign reviews to user: The user can either select a submission himself, which he wants to review, or the site can suggest a review to the user. Currently, the user can give more than two reviews. The ReviewMapping controller had a method so that all the users are assigned reviews automatically. Originally, the plan was to assign only a fixed number of reviews to each user. The dynamic review controller helped the review mapping controller assign reviews so that the reviews are never mapped such that the last user does not have any review to map, except his own. For example, consider three users, U1, U2 and U3. If U1 is assigned U2's work and U2 is assigned U1's work, U3 would not have any work to review. The dynamic review mapping controller makes sure that such a condition does not occur.

We were supposed to refactor these controllers. The ReportsController did not have any known use, and the DynamicReviewMapping Controller had changes to be made to make it conform to standards.

==Modification to Existing Code==

===ReportsController===
After searching through various controllers, looking for references used in the controller, we figured out that the code in the ReportsController was actually copied from the ResponseController, in December 2013. The ResponseController has been refactored since, and thus is an updated version. As of the usage, only the ResponseController has been referenced, and the ReportsController had never been used. We also extracted an older version of the ReportsController, that is, the one before it was replaced with code from the ResponseController. The code had a single method, and the method did not have any useful functionality. It was, thus, decided that the ReportsController should be removed from the Expertiza project, and that removing it would not have any effect on the overall project. Keeping it in would, on the other hand, create confusion for other people who would work on the project later.

===DynamicReviewMapping Controller===
*The code block between line 808 to 825 was duplicated in 3 places in this file. We have refactored the code to remove this bad smell. We have created a method called create_message to avoid duplication in the code. (Violated the DRY Principle. Eliminated duplication in code)

*Method assign_metareviewers, assign_reviewers_team were too long. We have made two new methods (check_assignment_for_review and show_message_for_review_count) that does just one task and does it perfectly instead of large methods to do multiple tasks. (Violated the Single Responsibility Principle and the DRY Principle. Eliminated lengthy methods and meaningless method names)

*Method assign_reviewers_individual was not used anymore. We have checked for its functionality and deleted it since it did not play any role in the final application. (Eliminated unnecessary methods)

*We have changed if to unless wherever necessary.

*Changed " == 0" expression to ".zero?"

*Used if (var) instead of if (var == true)

*We have used array checking and made changes according to the following rules:

**Use [].empty? instead of [].length == 0 or [].length.zero?
**Use [:foo].any? instead of [:foo].length > 0
**Use [:foo].one? instead of [:foo].length == 1
**Use [:foo].first instead of [:foo][0]
**Use [:foo].last instead of [:foo][-1]

*We have used && and || rather than and and or to keep boolean precedence.

None of this would actually change the functionality of the code. To make sure, we tried to look for the usage of the code. Again, after extensive searching, we figured that the code was never used. The DynamicReviewMapping controller, as stated above, depended on a set of rules that were not applicable anymore. The controller exists so that it is available, in case the rules are reverted to the original one. As such, currently the Controller is not used. We made the changes, but we have no way to check the code. We did the best we could, and we are sure that there are no errors in the refactored code.

==Further Reading==
*[http://www.refactoringinruby.com/ Refactoring In Ruby]
*[http://refactoring.com/ Refactoring]

==References==
<references/>

CSC/ECE 517 Fall 2014/oss E1457 ags

2014-11-06T03:12:56Z

Gshah: /* DynamicReviewMapping Controller */

=Expertiza - Refactoring DynamicReviewMapping Controller and the ReportsController=

__TOC__

==Introduction==
It is time consuming to assess project work in a large classroom environment, and one of the best techniques to achieve this is to have students assist in this assessment. If each student is asked to assess a few (say, one to five) other students or student teams, the task requires a reasonable amount of effort; and that effort does not increase as the class gets larger. "''Expertiza is a system for managing all kinds of communication that is involved in assessment: double-blind communications between authors and reviewers, assessment of teammate contributions, evaluations by course staff, and surveys of students to assess the assignment and the
peer-review process.''" <ref>http://www.igi-global.com/book/monitoring-assessment-online-collaborative-environments/773&f=e-book</ref>
''"Expertiza project uses peer review to create reusable learning objects.''"<ref>http://expertiza.ncsu.edu/</ref> Students select from a list of tasks to be performed, with several students selecting each task. Then they prepare their work and submit it to an electronic peer-review system. The work is then reviewed by other students, who offer comments to help the submitters improve their work. The best submissions for each task are then selected for use in later courses. Expertiza gets students working together to improve others’ learning experiences. It helps them learn, by making them think through the lecture material and apply it to a real-world situation, just as they might do in an on-the-job situation. These learning objects can be improved iteratively; for example, the next year’s class can be presented with the examples developed by students the previous year, and asked to identify shortcomings and develop improved examples.<ref>http://scholar.google.com/scholar?q=%22Reusable+learning+objects+through+peer+review%3A+The+Expertiza+approach%22+%22The+Expertiza+platform+is+a+divide-and-conquer%22&btnG=&hl=en&as_sdt=0%2C34</ref> More information on Expertiza can be found [https://github.com/expertiza/expertiza here].

==Refactoring in Ruby==
Refactoring helps to<ref>http://www.refactoringinruby.com/</ref>
*Understand what led to poor code design
*Fix code which is difficult to understand
*Express each idea “once and only once”
*Recognize missing or inadequately formed classes
*Simplify overly complex relationships between classes
*Achieve the right balance of responsibilities among objects
*Make code easier to test and more maintainable

===Code Smells===
We identified the following categories of code smells in the helper module:

*Lengthy Definitions: These are the methods that have too many responsibilities and collaborators. As a result of which, their overall length has grown too long reducing the maintainability and readability.

*Duplicated Code: These are those pieces of code that does almost the same functionality of some other piece of code leading to a bad design style. They are usually too error prone since not everyone identifies all the code responsible for the same task and does the changes whenever the need arises.

*Bad method names: A good method name is expected to adhere to the Ruby style and design style guidelines. It is expected to convey a reasonable amount of responsibilities handled. A good method name in combination with good practices should resemble a user story.

*Used and unnecessary methods: These are those methods that were useful when the code was first developed. But, they lost their functionality as the code got updated and new functionalities were added or existing ones were modified.

===Refactoring Techniques===
There are many documented refactoring techniques, and a few common ones are below.<ref>http://www.integralist.co.uk/posts/refactoring-techniques/</ref>
*'''Rename Method''': Renaming identifiers can reduce the need for code comments and nearly always helps to promote greater clarity.
*'''Introduce Explaining Variable''': So here is a technique specifically based around the premise of renaming.
For example:
<pre>
unless "This is a String with some CAPS".scan(/([A-Z])/).empty?
puts "capitalised text was found"
end
</pre>
Should be:
<pre>
caps_not_found = "This is a String with some CAPS".scan(/([A-Z])/).empty?

unless caps_not_found
puts "capitalised text was found"
end
</pre>

*'''Extract Method''': It consists of breaking up long methods by shifting overly complex chunks of code into new methods which have very descriptive identifiers.
For example:
<pre>
class Foo
attr_reader :bar

def initialize bar
@bar = bar
end

def do_something
puts "my baz" # notice this is duplication
puts bar
end

def do_something_else
puts "my baz" # notice this is duplication
puts "Something else"
puts bar
end
end
</pre>

Becomes:
<pre>
class Foo
attr_reader :bar

def initialize bar
@bar = bar
end

def do_something
baz
puts bar
end

def do_something_else
baz
puts "Something else"
puts bar
end

def baz
puts "my baz"
end
end
</pre>

*'''Inline Method''': Sometimes you want the opposite of the Extract Method technique. Imagine a method exists whose content is already simple and clear, and whose identifier adds no extra benefit. So to fix this problem we'll convert the method invocation into an inlined piece of code.

*'''Pull Up Method''': When you have duplicated code across two separate classes then the best refactoring technique to implement is to pull that duplicate code up into a super class so we DRY (Don't Repeat Yourself) out the code and allow it to be used in multiple places without duplication (meaning changes in future only have to happen in one place).

For example:
<pre>
class Person
attr_reader :first_name, :last_name

def initialize first_name, last_name
@first_name = first_name
@last_name = last_name
end

end

class MalePerson < Person
# This is duplicated in the `FemalePerson` class
def full_name
first_name + " " + last_name
end

def gender
"M"
end
end

class FemalePerson < Person
# This is duplicated in the `MalePerson` class
def full_name
first_name + " " + last_name
end

def gender
"F"
end
end
</pre>
Becomes:
<pre>
class Person
attr_reader :first_name, :last_name

def initialize first_name, last_name
@first_name = first_name
@last_name = last_name
end

def full_name
first_name + " " + last_name
end
end

class MalePerson < Person
def gender
"M"
end
end

class FemalePerson < Person
def gender
"F"
end
end
</pre>

*'''Introduce Named Parameter''':When method arguments are unclear then convert them into named parameters so they become clearer (and easier to remember).

==Project Description==

We were supposed to refactor two controllers, the ReportsController and the DynamicReviewMapping Controller. The ReportsController was thought to be generating reports for students, showing all their scores in a single page. The DynamicReviewMapping Controller is actually a helper to the ReviewMapping controller. The review mapping controller maps reviews to each user. Currently, there are two ways to assign reviews to user: The user can either select a submission himself, which he wants to review, or the site can suggest a review to the user. Currently, the user can give more than two reviews. The ReviewMapping controller had a method so that all the users are assigned reviews automatically. Originally, the plan was to assign only a fixed number of reviews to each user. The dynamic review controller helped the review mapping controller assign reviews so that the reviews are never mapped such that the last user does not have any review to map, except his own. For example, consider three users, U1, U2 and U3. If U1 is assigned U2's work and U2 is assigned U1's work, U3 would not have any work to review. The dynamic review mapping controller makes sure that such a condition does not occur.

We were supposed to refactor these controllers. The ReportsController did not have any known use, and the DynamicReviewMapping Controller had changes to be made to make it conform to standards.

==Modification to Existing Code==

===ReportsController===
After searching through various controllers, looking for references used in the controller, we figured out that the code in the ReportsController was actually copied from the ResponseController, in December 2013. The ResponseController has been refactored since, and thus is an updated version. As of the usage, only the ResponseController has been referenced, and the ReportsController had never been used. We also extracted an older version of the ReportsController, that is, the one before it was replaced with code from the ResponseController. The code had a single method, and the method did not have any useful functionality. It was, thus, decided that the ReportsController should be removed from the Expertiza project, and that removing it would not have any effect on the overall project. Keeping it in would, on the other hand, create confusion for other people who would work on the project later.

===DynamicReviewMapping Controller===
*The code block between line 808 to 825 was duplicated in 3 places in this file. We have refactored the code to remove this bad smell. We have created a method called create_message to avoid duplication in the code. (Violated the DRY Principle. Eliminated duplication in code)

*Method assign_metareviewers, assign_reviewers_team were too long. We have made two new methods (check_assignment_for_review and show_message_for_review_count) that does just one task and does it perfectly instead of large methods to do multiple tasks. (Violated the Single Responsibility Principle and the DRY Principle. Eliminated lengthy methods and meaningless method names)

*Method assign_reviewers_individual was not used anymore. We have checked for its functionality and deleted it since it did not play any role in the final application. (Eliminated unnecessary methods)

*We have changed if to unless wherever necessary.

*Changed " == 0" expression to ".zero?"

*Used if (var) instead of if (var == true)

*We have used array checking and made changes according to the following rules:

**Use [].empty? instead of [].length == 0 or [].length.zero?
**Use [:foo].any? instead of [:foo].length > 0
**Use [:foo].one? instead of [:foo].length == 1
**Use [:foo].first instead of [:foo][0]
**Use [:foo].last instead of [:foo][-1]

*We have used && and || rather than and and or to keep boolean precedence.

None of this would actually change the functionality of the code. To make sure, we tried to look for the usage of the code. Again, after extensive searching, we figured that the code was never used. The DynamicReviewMapping controller, as stated above, depended on a set of rules that were not applicable anymore. The controller exists so that it is available, in case the rules are reverted to the original one. As such, currently the Controller is not used. We made the changes, but we have no way to check the code. We did the best we could, and we are sure that there are no errors in the refactored code.

==Further Reading==
*[http://www.refactoringinruby.com/ Refactoring In Ruby]
*[http://refactoring.com/ Refactoring]

==References==
<references/>

CSC/ECE 517 Fall 2014/oss E1457 ags

2014-11-06T03:11:38Z

Gshah: /* DynamicReviewMapping Controller */

=Expertiza - Refactoring DynamicReviewMapping Controller and the ReportsController=

__TOC__

==Introduction==
It is time consuming to assess project work in a large classroom environment, and one of the best techniques to achieve this is to have students assist in this assessment. If each student is asked to assess a few (say, one to five) other students or student teams, the task requires a reasonable amount of effort; and that effort does not increase as the class gets larger. "''Expertiza is a system for managing all kinds of communication that is involved in assessment: double-blind communications between authors and reviewers, assessment of teammate contributions, evaluations by course staff, and surveys of students to assess the assignment and the
peer-review process.''" <ref>http://www.igi-global.com/book/monitoring-assessment-online-collaborative-environments/773&f=e-book</ref>
''"Expertiza project uses peer review to create reusable learning objects.''"<ref>http://expertiza.ncsu.edu/</ref> Students select from a list of tasks to be performed, with several students selecting each task. Then they prepare their work and submit it to an electronic peer-review system. The work is then reviewed by other students, who offer comments to help the submitters improve their work. The best submissions for each task are then selected for use in later courses. Expertiza gets students working together to improve others’ learning experiences. It helps them learn, by making them think through the lecture material and apply it to a real-world situation, just as they might do in an on-the-job situation. These learning objects can be improved iteratively; for example, the next year’s class can be presented with the examples developed by students the previous year, and asked to identify shortcomings and develop improved examples.<ref>http://scholar.google.com/scholar?q=%22Reusable+learning+objects+through+peer+review%3A+The+Expertiza+approach%22+%22The+Expertiza+platform+is+a+divide-and-conquer%22&btnG=&hl=en&as_sdt=0%2C34</ref> More information on Expertiza can be found [https://github.com/expertiza/expertiza here].

==Refactoring in Ruby==
Refactoring helps to<ref>http://www.refactoringinruby.com/</ref>
*Understand what led to poor code design
*Fix code which is difficult to understand
*Express each idea “once and only once”
*Recognize missing or inadequately formed classes
*Simplify overly complex relationships between classes
*Achieve the right balance of responsibilities among objects
*Make code easier to test and more maintainable

===Code Smells===
We identified the following categories of code smells in the helper module:

*Lengthy Definitions: These are the methods that have too many responsibilities and collaborators. As a result of which, their overall length has grown too long reducing the maintainability and readability.

*Duplicated Code: These are those pieces of code that does almost the same functionality of some other piece of code leading to a bad design style. They are usually too error prone since not everyone identifies all the code responsible for the same task and does the changes whenever the need arises.

*Bad method names: A good method name is expected to adhere to the Ruby style and design style guidelines. It is expected to convey a reasonable amount of responsibilities handled. A good method name in combination with good practices should resemble a user story.

*Used and unnecessary methods: These are those methods that were useful when the code was first developed. But, they lost their functionality as the code got updated and new functionalities were added or existing ones were modified.

===Refactoring Techniques===
There are many documented refactoring techniques, and a few common ones are below.<ref>http://www.integralist.co.uk/posts/refactoring-techniques/</ref>
*'''Rename Method''': Renaming identifiers can reduce the need for code comments and nearly always helps to promote greater clarity.
*'''Introduce Explaining Variable''': So here is a technique specifically based around the premise of renaming.
For example:
<pre>
unless "This is a String with some CAPS".scan(/([A-Z])/).empty?
puts "capitalised text was found"
end
</pre>
Should be:
<pre>
caps_not_found = "This is a String with some CAPS".scan(/([A-Z])/).empty?

unless caps_not_found
puts "capitalised text was found"
end
</pre>

*'''Extract Method''': It consists of breaking up long methods by shifting overly complex chunks of code into new methods which have very descriptive identifiers.
For example:
<pre>
class Foo
attr_reader :bar

def initialize bar
@bar = bar
end

def do_something
puts "my baz" # notice this is duplication
puts bar
end

def do_something_else
puts "my baz" # notice this is duplication
puts "Something else"
puts bar
end
end
</pre>

Becomes:
<pre>
class Foo
attr_reader :bar

def initialize bar
@bar = bar
end

def do_something
baz
puts bar
end

def do_something_else
baz
puts "Something else"
puts bar
end

def baz
puts "my baz"
end
end
</pre>

*'''Inline Method''': Sometimes you want the opposite of the Extract Method technique. Imagine a method exists whose content is already simple and clear, and whose identifier adds no extra benefit. So to fix this problem we'll convert the method invocation into an inlined piece of code.

*'''Pull Up Method''': When you have duplicated code across two separate classes then the best refactoring technique to implement is to pull that duplicate code up into a super class so we DRY (Don't Repeat Yourself) out the code and allow it to be used in multiple places without duplication (meaning changes in future only have to happen in one place).

For example:
<pre>
class Person
attr_reader :first_name, :last_name

def initialize first_name, last_name
@first_name = first_name
@last_name = last_name
end

end

class MalePerson < Person
# This is duplicated in the `FemalePerson` class
def full_name
first_name + " " + last_name
end

def gender
"M"
end
end

class FemalePerson < Person
# This is duplicated in the `MalePerson` class
def full_name
first_name + " " + last_name
end

def gender
"F"
end
end
</pre>
Becomes:
<pre>
class Person
attr_reader :first_name, :last_name

def initialize first_name, last_name
@first_name = first_name
@last_name = last_name
end

def full_name
first_name + " " + last_name
end
end

class MalePerson < Person
def gender
"M"
end
end

class FemalePerson < Person
def gender
"F"
end
end
</pre>

*'''Introduce Named Parameter''':When method arguments are unclear then convert them into named parameters so they become clearer (and easier to remember).

==Project Description==

We were supposed to refactor two controllers, the ReportsController and the DynamicReviewMapping Controller. The ReportsController was thought to be generating reports for students, showing all their scores in a single page. The DynamicReviewMapping Controller is actually a helper to the ReviewMapping controller. The review mapping controller maps reviews to each user. Currently, there are two ways to assign reviews to user: The user can either select a submission himself, which he wants to review, or the site can suggest a review to the user. Currently, the user can give more than two reviews. The ReviewMapping controller had a method so that all the users are assigned reviews automatically. Originally, the plan was to assign only a fixed number of reviews to each user. The dynamic review controller helped the review mapping controller assign reviews so that the reviews are never mapped such that the last user does not have any review to map, except his own. For example, consider three users, U1, U2 and U3. If U1 is assigned U2's work and U2 is assigned U1's work, U3 would not have any work to review. The dynamic review mapping controller makes sure that such a condition does not occur.

We were supposed to refactor these controllers. The ReportsController did not have any known use, and the DynamicReviewMapping Controller had changes to be made to make it conform to standards.

==Modification to Existing Code==

===ReportsController===
After searching through various controllers, looking for references used in the controller, we figured out that the code in the ReportsController was actually copied from the ResponseController, in December 2013. The ResponseController has been refactored since, and thus is an updated version. As of the usage, only the ResponseController has been referenced, and the ReportsController had never been used. We also extracted an older version of the ReportsController, that is, the one before it was replaced with code from the ResponseController. The code had a single method, and the method did not have any useful functionality. It was, thus, decided that the ReportsController should be removed from the Expertiza project, and that removing it would not have any effect on the overall project. Keeping it in would, on the other hand, create confusion for other people who would work on the project later.

===DynamicReviewMapping Controller===
*The code block between line 808 to 825 was duplicated in 3 places in this file. We have refactored the code to remove this bad smell. We have created a method called create_message to avoid duplication in the code. (Violated the DRY Principle)

*Method assign_metareviewers, assign_reviewers_team were too long. We have made two new methods (check_assignment_for_review and show_message_for_review_count) that does just one task and does it perfectly instead of large methods to do multiple tasks. (Violated the Single Responsibility Principle and the DRY Principle. Eliminated lengthy methods and meaningless method names)

*Method assign_reviewers_individual was not used anymore. We have checked for its functionality and deleted it since it did not play any role in the final application. (Eliminated unnecessary methods)

*We have changed if to unless wherever necessary.

*Changed " == 0" expression to ".zero?"

*Used if (var) instead of if (var == true)

*We have used array checking and made changes according to the following rules:

**Use [].empty? instead of [].length == 0 or [].length.zero?
**Use [:foo].any? instead of [:foo].length > 0
**Use [:foo].one? instead of [:foo].length == 1
**Use [:foo].first instead of [:foo][0]
**Use [:foo].last instead of [:foo][-1]

*We have used && and || rather than and and or to keep boolean precedence.

None of this would actually change the functionality of the code. To make sure, we tried to look for the usage of the code. Again, after extensive searching, we figured that the code was never used. The DynamicReviewMapping controller, as stated above, depended on a set of rules that were not applicable anymore. The controller exists so that it is available, in case the rules are reverted to the original one. As such, currently the Controller is not used. We made the changes, but we have no way to check the code. We did the best we could, and we are sure that there are no errors in the refactored code.

==Further Reading==
*[http://www.refactoringinruby.com/ Refactoring In Ruby]
*[http://refactoring.com/ Refactoring]

==References==
<references/>

CSC/ECE 517 Fall 2014/oss E1457 ags

2014-11-06T03:10:17Z

Gshah: /* DynamicReviewMapping Controller */

=Expertiza - Refactoring DynamicReviewMapping Controller and the ReportsController=

__TOC__

==Introduction==
It is time consuming to assess project work in a large classroom environment, and one of the best techniques to achieve this is to have students assist in this assessment. If each student is asked to assess a few (say, one to five) other students or student teams, the task requires a reasonable amount of effort; and that effort does not increase as the class gets larger. "''Expertiza is a system for managing all kinds of communication that is involved in assessment: double-blind communications between authors and reviewers, assessment of teammate contributions, evaluations by course staff, and surveys of students to assess the assignment and the
peer-review process.''" <ref>http://www.igi-global.com/book/monitoring-assessment-online-collaborative-environments/773&f=e-book</ref>
''"Expertiza project uses peer review to create reusable learning objects.''"<ref>http://expertiza.ncsu.edu/</ref> Students select from a list of tasks to be performed, with several students selecting each task. Then they prepare their work and submit it to an electronic peer-review system. The work is then reviewed by other students, who offer comments to help the submitters improve their work. The best submissions for each task are then selected for use in later courses. Expertiza gets students working together to improve others’ learning experiences. It helps them learn, by making them think through the lecture material and apply it to a real-world situation, just as they might do in an on-the-job situation. These learning objects can be improved iteratively; for example, the next year’s class can be presented with the examples developed by students the previous year, and asked to identify shortcomings and develop improved examples.<ref>http://scholar.google.com/scholar?q=%22Reusable+learning+objects+through+peer+review%3A+The+Expertiza+approach%22+%22The+Expertiza+platform+is+a+divide-and-conquer%22&btnG=&hl=en&as_sdt=0%2C34</ref> More information on Expertiza can be found [https://github.com/expertiza/expertiza here].

==Refactoring in Ruby==
Refactoring helps to<ref>http://www.refactoringinruby.com/</ref>
*Understand what led to poor code design
*Fix code which is difficult to understand
*Express each idea “once and only once”
*Recognize missing or inadequately formed classes
*Simplify overly complex relationships between classes
*Achieve the right balance of responsibilities among objects
*Make code easier to test and more maintainable

===Code Smells===
We identified the following categories of code smells in the helper module:

*Lengthy Definitions: These are the methods that have too many responsibilities and collaborators. As a result of which, their overall length has grown too long reducing the maintainability and readability.

*Duplicated Code: These are those pieces of code that does almost the same functionality of some other piece of code leading to a bad design style. They are usually too error prone since not everyone identifies all the code responsible for the same task and does the changes whenever the need arises.

*Bad method names: A good method name is expected to adhere to the Ruby style and design style guidelines. It is expected to convey a reasonable amount of responsibilities handled. A good method name in combination with good practices should resemble a user story.

*Used and unnecessary methods: These are those methods that were useful when the code was first developed. But, they lost their functionality as the code got updated and new functionalities were added or existing ones were modified.

===Refactoring Techniques===
There are many documented refactoring techniques, and a few common ones are below.<ref>http://www.integralist.co.uk/posts/refactoring-techniques/</ref>
*'''Rename Method''': Renaming identifiers can reduce the need for code comments and nearly always helps to promote greater clarity.
*'''Introduce Explaining Variable''': So here is a technique specifically based around the premise of renaming.
For example:
<pre>
unless "This is a String with some CAPS".scan(/([A-Z])/).empty?
puts "capitalised text was found"
end
</pre>
Should be:
<pre>
caps_not_found = "This is a String with some CAPS".scan(/([A-Z])/).empty?

unless caps_not_found
puts "capitalised text was found"
end
</pre>

*'''Extract Method''': It consists of breaking up long methods by shifting overly complex chunks of code into new methods which have very descriptive identifiers.
For example:
<pre>
class Foo
attr_reader :bar

def initialize bar
@bar = bar
end

def do_something
puts "my baz" # notice this is duplication
puts bar
end

def do_something_else
puts "my baz" # notice this is duplication
puts "Something else"
puts bar
end
end
</pre>

Becomes:
<pre>
class Foo
attr_reader :bar

def initialize bar
@bar = bar
end

def do_something
baz
puts bar
end

def do_something_else
baz
puts "Something else"
puts bar
end

def baz
puts "my baz"
end
end
</pre>

*'''Inline Method''': Sometimes you want the opposite of the Extract Method technique. Imagine a method exists whose content is already simple and clear, and whose identifier adds no extra benefit. So to fix this problem we'll convert the method invocation into an inlined piece of code.

*'''Pull Up Method''': When you have duplicated code across two separate classes then the best refactoring technique to implement is to pull that duplicate code up into a super class so we DRY (Don't Repeat Yourself) out the code and allow it to be used in multiple places without duplication (meaning changes in future only have to happen in one place).

For example:
<pre>
class Person
attr_reader :first_name, :last_name

def initialize first_name, last_name
@first_name = first_name
@last_name = last_name
end

end

class MalePerson < Person
# This is duplicated in the `FemalePerson` class
def full_name
first_name + " " + last_name
end

def gender
"M"
end
end

class FemalePerson < Person
# This is duplicated in the `MalePerson` class
def full_name
first_name + " " + last_name
end

def gender
"F"
end
end
</pre>
Becomes:
<pre>
class Person
attr_reader :first_name, :last_name

def initialize first_name, last_name
@first_name = first_name
@last_name = last_name
end

def full_name
first_name + " " + last_name
end
end

class MalePerson < Person
def gender
"M"
end
end

class FemalePerson < Person
def gender
"F"
end
end
</pre>

*'''Introduce Named Parameter''':When method arguments are unclear then convert them into named parameters so they become clearer (and easier to remember).

==Project Description==

We were supposed to refactor two controllers, the ReportsController and the DynamicReviewMapping Controller. The ReportsController was thought to be generating reports for students, showing all their scores in a single page. The DynamicReviewMapping Controller is actually a helper to the ReviewMapping controller. The review mapping controller maps reviews to each user. Currently, there are two ways to assign reviews to user: The user can either select a submission himself, which he wants to review, or the site can suggest a review to the user. Currently, the user can give more than two reviews. The ReviewMapping controller had a method so that all the users are assigned reviews automatically. Originally, the plan was to assign only a fixed number of reviews to each user. The dynamic review controller helped the review mapping controller assign reviews so that the reviews are never mapped such that the last user does not have any review to map, except his own. For example, consider three users, U1, U2 and U3. If U1 is assigned U2's work and U2 is assigned U1's work, U3 would not have any work to review. The dynamic review mapping controller makes sure that such a condition does not occur.

We were supposed to refactor these controllers. The ReportsController did not have any known use, and the DynamicReviewMapping Controller had changes to be made to make it conform to standards.

==Modification to Existing Code==

===ReportsController===
After searching through various controllers, looking for references used in the controller, we figured out that the code in the ReportsController was actually copied from the ResponseController, in December 2013. The ResponseController has been refactored since, and thus is an updated version. As of the usage, only the ResponseController has been referenced, and the ReportsController had never been used. We also extracted an older version of the ReportsController, that is, the one before it was replaced with code from the ResponseController. The code had a single method, and the method did not have any useful functionality. It was, thus, decided that the ReportsController should be removed from the Expertiza project, and that removing it would not have any effect on the overall project. Keeping it in would, on the other hand, create confusion for other people who would work on the project later.

===DynamicReviewMapping Controller===
*The code block between line 808 to 825 was duplicated in 3 places in this file. We have refactored the code to remove this bad smell. We have created a method called create_message to avoid duplication in the code. (Violated the DRY Principle)

*Method assign_metareviewers, assign_reviewers_team were too long. We have made two new methods (check_assignment_for_review and show_message_for_review_count) that does just one task and does it perfectly instead of large methods to do multiple tasks. (Violated the Single Responsibility Principle and the DRY Principle)

*Method assign_reviewers_individual was not used anymore. We have checked for its functionality and deleted it since it did not play any role in the final application. (Eliminated
*We have changed if to unless wherever necessary.
*Changed " == 0" expression to ".zero?"
*Used if (var) instead of if (var == true)
*We have used array checking and made changes according to the following rules:

**Use [].empty? instead of [].length == 0 or [].length.zero?
**Use [:foo].any? instead of [:foo].length > 0
**Use [:foo].one? instead of [:foo].length == 1
**Use [:foo].first instead of [:foo][0]
**Use [:foo].last instead of [:foo][-1]
*We have used && and || rather than and and or to keep boolean precedence.

None of this would actually change the functionality of the code. To make sure, we tried to look for the usage of the code. Again, after extensive searching, we figured that the code was never used. The DynamicReviewMapping controller, as stated above, depended on a set of rules that were not applicable anymore. The controller exists so that it is available, in case the rules are reverted to the original one. As such, currently the Controller is not used. We made the changes, but we have no way to check the code. We did the best we could, and we are sure that there are no errors in the refactored code.

==Further Reading==
*[http://www.refactoringinruby.com/ Refactoring In Ruby]
*[http://refactoring.com/ Refactoring]

==References==
<references/>

CSC/ECE 517 Fall 2014/oss E1457 ags

2014-11-06T03:07:15Z

Gshah: /* DynamicReviewMapping Controller */

=Expertiza - Refactoring DynamicReviewMapping Controller and the ReportsController=

__TOC__

==Introduction==
It is time consuming to assess project work in a large classroom environment, and one of the best techniques to achieve this is to have students assist in this assessment. If each student is asked to assess a few (say, one to five) other students or student teams, the task requires a reasonable amount of effort; and that effort does not increase as the class gets larger. "''Expertiza is a system for managing all kinds of communication that is involved in assessment: double-blind communications between authors and reviewers, assessment of teammate contributions, evaluations by course staff, and surveys of students to assess the assignment and the
peer-review process.''" <ref>http://www.igi-global.com/book/monitoring-assessment-online-collaborative-environments/773&f=e-book</ref>
''"Expertiza project uses peer review to create reusable learning objects.''"<ref>http://expertiza.ncsu.edu/</ref> Students select from a list of tasks to be performed, with several students selecting each task. Then they prepare their work and submit it to an electronic peer-review system. The work is then reviewed by other students, who offer comments to help the submitters improve their work. The best submissions for each task are then selected for use in later courses. Expertiza gets students working together to improve others’ learning experiences. It helps them learn, by making them think through the lecture material and apply it to a real-world situation, just as they might do in an on-the-job situation. These learning objects can be improved iteratively; for example, the next year’s class can be presented with the examples developed by students the previous year, and asked to identify shortcomings and develop improved examples.<ref>http://scholar.google.com/scholar?q=%22Reusable+learning+objects+through+peer+review%3A+The+Expertiza+approach%22+%22The+Expertiza+platform+is+a+divide-and-conquer%22&btnG=&hl=en&as_sdt=0%2C34</ref> More information on Expertiza can be found [https://github.com/expertiza/expertiza here].

==Refactoring in Ruby==
Refactoring helps to<ref>http://www.refactoringinruby.com/</ref>
*Understand what led to poor code design
*Fix code which is difficult to understand
*Express each idea “once and only once”
*Recognize missing or inadequately formed classes
*Simplify overly complex relationships between classes
*Achieve the right balance of responsibilities among objects
*Make code easier to test and more maintainable

===Code Smells===
We identified the following categories of code smells in the helper module:

*Lengthy Definitions: These are the methods that have too many responsibilities and collaborators. As a result of which, their overall length has grown too long reducing the maintainability and readability.

*Duplicated Code: These are those pieces of code that does almost the same functionality of some other piece of code leading to a bad design style. They are usually too error prone since not everyone identifies all the code responsible for the same task and does the changes whenever the need arises.

*Bad method names: A good method name is expected to adhere to the Ruby style and design style guidelines. It is expected to convey a reasonable amount of responsibilities handled. A good method name in combination with good practices should resemble a user story.

*Used and unnecessary methods: These are those methods that were useful when the code was first developed. But, they lost their functionality as the code got updated and new functionalities were added or existing ones were modified.

===Refactoring Techniques===
There are many documented refactoring techniques, and a few common ones are below.<ref>http://www.integralist.co.uk/posts/refactoring-techniques/</ref>
*'''Rename Method''': Renaming identifiers can reduce the need for code comments and nearly always helps to promote greater clarity.
*'''Introduce Explaining Variable''': So here is a technique specifically based around the premise of renaming.
For example:
<pre>
unless "This is a String with some CAPS".scan(/([A-Z])/).empty?
puts "capitalised text was found"
end
</pre>
Should be:
<pre>
caps_not_found = "This is a String with some CAPS".scan(/([A-Z])/).empty?

unless caps_not_found
puts "capitalised text was found"
end
</pre>

*'''Extract Method''': It consists of breaking up long methods by shifting overly complex chunks of code into new methods which have very descriptive identifiers.
For example:
<pre>
class Foo
attr_reader :bar

def initialize bar
@bar = bar
end

def do_something
puts "my baz" # notice this is duplication
puts bar
end

def do_something_else
puts "my baz" # notice this is duplication
puts "Something else"
puts bar
end
end
</pre>

Becomes:
<pre>
class Foo
attr_reader :bar

def initialize bar
@bar = bar
end

def do_something
baz
puts bar
end

def do_something_else
baz
puts "Something else"
puts bar
end

def baz
puts "my baz"
end
end
</pre>

*'''Inline Method''': Sometimes you want the opposite of the Extract Method technique. Imagine a method exists whose content is already simple and clear, and whose identifier adds no extra benefit. So to fix this problem we'll convert the method invocation into an inlined piece of code.

*'''Pull Up Method''': When you have duplicated code across two separate classes then the best refactoring technique to implement is to pull that duplicate code up into a super class so we DRY (Don't Repeat Yourself) out the code and allow it to be used in multiple places without duplication (meaning changes in future only have to happen in one place).

For example:
<pre>
class Person
attr_reader :first_name, :last_name

def initialize first_name, last_name
@first_name = first_name
@last_name = last_name
end

end

class MalePerson < Person
# This is duplicated in the `FemalePerson` class
def full_name
first_name + " " + last_name
end

def gender
"M"
end
end

class FemalePerson < Person
# This is duplicated in the `MalePerson` class
def full_name
first_name + " " + last_name
end

def gender
"F"
end
end
</pre>
Becomes:
<pre>
class Person
attr_reader :first_name, :last_name

def initialize first_name, last_name
@first_name = first_name
@last_name = last_name
end

def full_name
first_name + " " + last_name
end
end

class MalePerson < Person
def gender
"M"
end
end

class FemalePerson < Person
def gender
"F"
end
end
</pre>

*'''Introduce Named Parameter''':When method arguments are unclear then convert them into named parameters so they become clearer (and easier to remember).

==Project Description==

We were supposed to refactor two controllers, the ReportsController and the DynamicReviewMapping Controller. The ReportsController was thought to be generating reports for students, showing all their scores in a single page. The DynamicReviewMapping Controller is actually a helper to the ReviewMapping controller. The review mapping controller maps reviews to each user. Currently, there are two ways to assign reviews to user: The user can either select a submission himself, which he wants to review, or the site can suggest a review to the user. Currently, the user can give more than two reviews. The ReviewMapping controller had a method so that all the users are assigned reviews automatically. Originally, the plan was to assign only a fixed number of reviews to each user. The dynamic review controller helped the review mapping controller assign reviews so that the reviews are never mapped such that the last user does not have any review to map, except his own. For example, consider three users, U1, U2 and U3. If U1 is assigned U2's work and U2 is assigned U1's work, U3 would not have any work to review. The dynamic review mapping controller makes sure that such a condition does not occur.

We were supposed to refactor these controllers. The ReportsController did not have any known use, and the DynamicReviewMapping Controller had changes to be made to make it conform to standards.

==Modification to Existing Code==

===ReportsController===
After searching through various controllers, looking for references used in the controller, we figured out that the code in the ReportsController was actually copied from the ResponseController, in December 2013. The ResponseController has been refactored since, and thus is an updated version. As of the usage, only the ResponseController has been referenced, and the ReportsController had never been used. We also extracted an older version of the ReportsController, that is, the one before it was replaced with code from the ResponseController. The code had a single method, and the method did not have any useful functionality. It was, thus, decided that the ReportsController should be removed from the Expertiza project, and that removing it would not have any effect on the overall project. Keeping it in would, on the other hand, create confusion for other people who would work on the project later.

===DynamicReviewMapping Controller===
*The code block between line 808 to 825 was duplicated in 3 places in this file. We have refactored the code to remove this bad smell. We have created a method called create_message to avoid duplication in the code.
*Method assign_metareviewers, assign_reviewers_team were too long. We have made two new methods (check_assignment_for_review and show_message_for_review_count) that does just one task and does it perfectly instead of large methods to do multiple tasks.
*Method assign_reviewers_individual was not used anymore. We have checked for its functionality and deleted it since it did not play any role in the final application.
*We have changed if to unless wherever necessary.
*Changed " == 0" expression to ".zero?"
*Used if (var) instead of if (var == true)
*We have used array checking and made changes according to the following rules:

**Use [].empty? instead of [].length == 0 or [].length.zero?
**Use [:foo].any? instead of [:foo].length > 0
**Use [:foo].one? instead of [:foo].length == 1
**Use [:foo].first instead of [:foo][0]
**Use [:foo].last instead of [:foo][-1]
*We have used && and || rather than and and or to keep boolean precedence.

None of this would actually change the functionality of the code. To make sure, we tried to look for the usage of the code. Again, after extensive searching, we figured that the code was never used. The DynamicReviewMapping controller, as stated above, depended on a set of rules that were not applicable anymore. The controller exists so that it is available, in case the rules are reverted to the original one. As such, currently the Controller is not used. We made the changes, but we have no way to check the code. We did the best we could, and we are sure that there are no errors in the refactored code.

==Further Reading==
*[http://www.refactoringinruby.com/ Refactoring In Ruby]
*[http://refactoring.com/ Refactoring]

==References==
<references/>

CSC/ECE 517 Fall 2014/oss E1457 ags

2014-11-06T03:06:43Z

Gshah: /* DynamicReviewMapping Controller */

=Expertiza - Refactoring DynamicReviewMapping Controller and the ReportsController=

__TOC__

==Introduction==
It is time consuming to assess project work in a large classroom environment, and one of the best techniques to achieve this is to have students assist in this assessment. If each student is asked to assess a few (say, one to five) other students or student teams, the task requires a reasonable amount of effort; and that effort does not increase as the class gets larger. "''Expertiza is a system for managing all kinds of communication that is involved in assessment: double-blind communications between authors and reviewers, assessment of teammate contributions, evaluations by course staff, and surveys of students to assess the assignment and the
peer-review process.''" <ref>http://www.igi-global.com/book/monitoring-assessment-online-collaborative-environments/773&f=e-book</ref>
''"Expertiza project uses peer review to create reusable learning objects.''"<ref>http://expertiza.ncsu.edu/</ref> Students select from a list of tasks to be performed, with several students selecting each task. Then they prepare their work and submit it to an electronic peer-review system. The work is then reviewed by other students, who offer comments to help the submitters improve their work. The best submissions for each task are then selected for use in later courses. Expertiza gets students working together to improve others’ learning experiences. It helps them learn, by making them think through the lecture material and apply it to a real-world situation, just as they might do in an on-the-job situation. These learning objects can be improved iteratively; for example, the next year’s class can be presented with the examples developed by students the previous year, and asked to identify shortcomings and develop improved examples.<ref>http://scholar.google.com/scholar?q=%22Reusable+learning+objects+through+peer+review%3A+The+Expertiza+approach%22+%22The+Expertiza+platform+is+a+divide-and-conquer%22&btnG=&hl=en&as_sdt=0%2C34</ref> More information on Expertiza can be found [https://github.com/expertiza/expertiza here].

==Refactoring in Ruby==
Refactoring helps to<ref>http://www.refactoringinruby.com/</ref>
*Understand what led to poor code design
*Fix code which is difficult to understand
*Express each idea “once and only once”
*Recognize missing or inadequately formed classes
*Simplify overly complex relationships between classes
*Achieve the right balance of responsibilities among objects
*Make code easier to test and more maintainable

===Code Smells===
We identified the following categories of code smells in the helper module:

*Lengthy Definitions: These are the methods that have too many responsibilities and collaborators. As a result of which, their overall length has grown too long reducing the maintainability and readability.

*Duplicated Code: These are those pieces of code that does almost the same functionality of some other piece of code leading to a bad design style. They are usually too error prone since not everyone identifies all the code responsible for the same task and does the changes whenever the need arises.

*Bad method names: A good method name is expected to adhere to the Ruby style and design style guidelines. It is expected to convey a reasonable amount of responsibilities handled. A good method name in combination with good practices should resemble a user story.

*Used and unnecessary methods: These are those methods that were useful when the code was first developed. But, they lost their functionality as the code got updated and new functionalities were added or existing ones were modified.

===Refactoring Techniques===
There are many documented refactoring techniques, and a few common ones are below.<ref>http://www.integralist.co.uk/posts/refactoring-techniques/</ref>
*'''Rename Method''': Renaming identifiers can reduce the need for code comments and nearly always helps to promote greater clarity.
*'''Introduce Explaining Variable''': So here is a technique specifically based around the premise of renaming.
For example:
<pre>
unless "This is a String with some CAPS".scan(/([A-Z])/).empty?
puts "capitalised text was found"
end
</pre>
Should be:
<pre>
caps_not_found = "This is a String with some CAPS".scan(/([A-Z])/).empty?

unless caps_not_found
puts "capitalised text was found"
end
</pre>

*'''Extract Method''': It consists of breaking up long methods by shifting overly complex chunks of code into new methods which have very descriptive identifiers.
For example:
<pre>
class Foo
attr_reader :bar

def initialize bar
@bar = bar
end

def do_something
puts "my baz" # notice this is duplication
puts bar
end

def do_something_else
puts "my baz" # notice this is duplication
puts "Something else"
puts bar
end
end
</pre>

Becomes:
<pre>
class Foo
attr_reader :bar

def initialize bar
@bar = bar
end

def do_something
baz
puts bar
end

def do_something_else
baz
puts "Something else"
puts bar
end

def baz
puts "my baz"
end
end
</pre>

*'''Inline Method''': Sometimes you want the opposite of the Extract Method technique. Imagine a method exists whose content is already simple and clear, and whose identifier adds no extra benefit. So to fix this problem we'll convert the method invocation into an inlined piece of code.

*'''Pull Up Method''': When you have duplicated code across two separate classes then the best refactoring technique to implement is to pull that duplicate code up into a super class so we DRY (Don't Repeat Yourself) out the code and allow it to be used in multiple places without duplication (meaning changes in future only have to happen in one place).

For example:
<pre>
class Person
attr_reader :first_name, :last_name

def initialize first_name, last_name
@first_name = first_name
@last_name = last_name
end

end

class MalePerson < Person
# This is duplicated in the `FemalePerson` class
def full_name
first_name + " " + last_name
end

def gender
"M"
end
end

class FemalePerson < Person
# This is duplicated in the `MalePerson` class
def full_name
first_name + " " + last_name
end

def gender
"F"
end
end
</pre>
Becomes:
<pre>
class Person
attr_reader :first_name, :last_name

def initialize first_name, last_name
@first_name = first_name
@last_name = last_name
end

def full_name
first_name + " " + last_name
end
end

class MalePerson < Person
def gender
"M"
end
end

class FemalePerson < Person
def gender
"F"
end
end
</pre>

*'''Introduce Named Parameter''':When method arguments are unclear then convert them into named parameters so they become clearer (and easier to remember).

==Project Description==

We were supposed to refactor two controllers, the ReportsController and the DynamicReviewMapping Controller. The ReportsController was thought to be generating reports for students, showing all their scores in a single page. The DynamicReviewMapping Controller is actually a helper to the ReviewMapping controller. The review mapping controller maps reviews to each user. Currently, there are two ways to assign reviews to user: The user can either select a submission himself, which he wants to review, or the site can suggest a review to the user. Currently, the user can give more than two reviews. The ReviewMapping controller had a method so that all the users are assigned reviews automatically. Originally, the plan was to assign only a fixed number of reviews to each user. The dynamic review controller helped the review mapping controller assign reviews so that the reviews are never mapped such that the last user does not have any review to map, except his own. For example, consider three users, U1, U2 and U3. If U1 is assigned U2's work and U2 is assigned U1's work, U3 would not have any work to review. The dynamic review mapping controller makes sure that such a condition does not occur.

We were supposed to refactor these controllers. The ReportsController did not have any known use, and the DynamicReviewMapping Controller had changes to be made to make it conform to standards.

==Modification to Existing Code==

===ReportsController===
After searching through various controllers, looking for references used in the controller, we figured out that the code in the ReportsController was actually copied from the ResponseController, in December 2013. The ResponseController has been refactored since, and thus is an updated version. As of the usage, only the ResponseController has been referenced, and the ReportsController had never been used. We also extracted an older version of the ReportsController, that is, the one before it was replaced with code from the ResponseController. The code had a single method, and the method did not have any useful functionality. It was, thus, decided that the ReportsController should be removed from the Expertiza project, and that removing it would not have any effect on the overall project. Keeping it in would, on the other hand, create confusion for other people who would work on the project later.

===DynamicReviewMapping Controller===
*The code block between line 808 to 825 was duplicated in 3 places in this file. We have refactored the code to remove this bad smell. We have created a method called create_message to avoid duplication in the code.
*Method assign_metareviewers, assign_reviewers_team were too long. We have made two new methods (check_assignment_for_review and show_message_for_review_count) that does just one task and does it perfectly instead of large methods to do multiple tasks.
*Method assign_reviewers_individual was not used anymore. We have checked for its functionality and deleted it since it did not play any role in the final application.
*We have changed if to unless wherever necessary.
*Changed " == 0" expression to ".zero?"
*Used if (var) instead of if (var == true)
*We have used array checking and made changes according to the following rules:

*Use [].empty? instead of [].length == 0 or [].length.zero?
**Use [:foo].any? instead of [:foo].length > 0
**Use [:foo].one? instead of [:foo].length == 1
**Use [:foo].first instead of [:foo][0]
**Use [:foo].last instead of [:foo][-1]
*We have used && and || rather than and and or to keep boolean precedence.

None of this would actually change the functionality of the code. To make sure, we tried to look for the usage of the code. Again, after extensive searching, we figured that the code was never used. The DynamicReviewMapping controller, as stated above, depended on a set of rules that were not applicable anymore. The controller exists so that it is available, in case the rules are reverted to the original one. As such, currently the Controller is not used. We made the changes, but we have no way to check the code. We did the best we could, and we are sure that there are no errors in the refactored code.

==Further Reading==
*[http://www.refactoringinruby.com/ Refactoring In Ruby]
*[http://refactoring.com/ Refactoring]

==References==
<references/>

CSC/ECE 517 Fall 2014/oss E1457 ags

2014-11-06T03:06:20Z

Gshah: /* DynamicReviewMapping Controller */

=Expertiza - Refactoring DynamicReviewMapping Controller and the ReportsController=

__TOC__

==Introduction==
It is time consuming to assess project work in a large classroom environment, and one of the best techniques to achieve this is to have students assist in this assessment. If each student is asked to assess a few (say, one to five) other students or student teams, the task requires a reasonable amount of effort; and that effort does not increase as the class gets larger. "''Expertiza is a system for managing all kinds of communication that is involved in assessment: double-blind communications between authors and reviewers, assessment of teammate contributions, evaluations by course staff, and surveys of students to assess the assignment and the
peer-review process.''" <ref>http://www.igi-global.com/book/monitoring-assessment-online-collaborative-environments/773&f=e-book</ref>
''"Expertiza project uses peer review to create reusable learning objects.''"<ref>http://expertiza.ncsu.edu/</ref> Students select from a list of tasks to be performed, with several students selecting each task. Then they prepare their work and submit it to an electronic peer-review system. The work is then reviewed by other students, who offer comments to help the submitters improve their work. The best submissions for each task are then selected for use in later courses. Expertiza gets students working together to improve others’ learning experiences. It helps them learn, by making them think through the lecture material and apply it to a real-world situation, just as they might do in an on-the-job situation. These learning objects can be improved iteratively; for example, the next year’s class can be presented with the examples developed by students the previous year, and asked to identify shortcomings and develop improved examples.<ref>http://scholar.google.com/scholar?q=%22Reusable+learning+objects+through+peer+review%3A+The+Expertiza+approach%22+%22The+Expertiza+platform+is+a+divide-and-conquer%22&btnG=&hl=en&as_sdt=0%2C34</ref> More information on Expertiza can be found [https://github.com/expertiza/expertiza here].

==Refactoring in Ruby==
Refactoring helps to<ref>http://www.refactoringinruby.com/</ref>
*Understand what led to poor code design
*Fix code which is difficult to understand
*Express each idea “once and only once”
*Recognize missing or inadequately formed classes
*Simplify overly complex relationships between classes
*Achieve the right balance of responsibilities among objects
*Make code easier to test and more maintainable

===Code Smells===
We identified the following categories of code smells in the helper module:

*Lengthy Definitions: These are the methods that have too many responsibilities and collaborators. As a result of which, their overall length has grown too long reducing the maintainability and readability.

*Duplicated Code: These are those pieces of code that does almost the same functionality of some other piece of code leading to a bad design style. They are usually too error prone since not everyone identifies all the code responsible for the same task and does the changes whenever the need arises.

*Bad method names: A good method name is expected to adhere to the Ruby style and design style guidelines. It is expected to convey a reasonable amount of responsibilities handled. A good method name in combination with good practices should resemble a user story.

*Used and unnecessary methods: These are those methods that were useful when the code was first developed. But, they lost their functionality as the code got updated and new functionalities were added or existing ones were modified.

===Refactoring Techniques===
There are many documented refactoring techniques, and a few common ones are below.<ref>http://www.integralist.co.uk/posts/refactoring-techniques/</ref>
*'''Rename Method''': Renaming identifiers can reduce the need for code comments and nearly always helps to promote greater clarity.
*'''Introduce Explaining Variable''': So here is a technique specifically based around the premise of renaming.
For example:
<pre>
unless "This is a String with some CAPS".scan(/([A-Z])/).empty?
puts "capitalised text was found"
end
</pre>
Should be:
<pre>
caps_not_found = "This is a String with some CAPS".scan(/([A-Z])/).empty?

unless caps_not_found
puts "capitalised text was found"
end
</pre>

*'''Extract Method''': It consists of breaking up long methods by shifting overly complex chunks of code into new methods which have very descriptive identifiers.
For example:
<pre>
class Foo
attr_reader :bar

def initialize bar
@bar = bar
end

def do_something
puts "my baz" # notice this is duplication
puts bar
end

def do_something_else
puts "my baz" # notice this is duplication
puts "Something else"
puts bar
end
end
</pre>

Becomes:
<pre>
class Foo
attr_reader :bar

def initialize bar
@bar = bar
end

def do_something
baz
puts bar
end

def do_something_else
baz
puts "Something else"
puts bar
end

def baz
puts "my baz"
end
end
</pre>

*'''Inline Method''': Sometimes you want the opposite of the Extract Method technique. Imagine a method exists whose content is already simple and clear, and whose identifier adds no extra benefit. So to fix this problem we'll convert the method invocation into an inlined piece of code.

*'''Pull Up Method''': When you have duplicated code across two separate classes then the best refactoring technique to implement is to pull that duplicate code up into a super class so we DRY (Don't Repeat Yourself) out the code and allow it to be used in multiple places without duplication (meaning changes in future only have to happen in one place).

For example:
<pre>
class Person
attr_reader :first_name, :last_name

def initialize first_name, last_name
@first_name = first_name
@last_name = last_name
end

end

class MalePerson < Person
# This is duplicated in the `FemalePerson` class
def full_name
first_name + " " + last_name
end

def gender
"M"
end
end

class FemalePerson < Person
# This is duplicated in the `MalePerson` class
def full_name
first_name + " " + last_name
end

def gender
"F"
end
end
</pre>
Becomes:
<pre>
class Person
attr_reader :first_name, :last_name

def initialize first_name, last_name
@first_name = first_name
@last_name = last_name
end

def full_name
first_name + " " + last_name
end
end

class MalePerson < Person
def gender
"M"
end
end

class FemalePerson < Person
def gender
"F"
end
end
</pre>

*'''Introduce Named Parameter''':When method arguments are unclear then convert them into named parameters so they become clearer (and easier to remember).

==Project Description==

We were supposed to refactor two controllers, the ReportsController and the DynamicReviewMapping Controller. The ReportsController was thought to be generating reports for students, showing all their scores in a single page. The DynamicReviewMapping Controller is actually a helper to the ReviewMapping controller. The review mapping controller maps reviews to each user. Currently, there are two ways to assign reviews to user: The user can either select a submission himself, which he wants to review, or the site can suggest a review to the user. Currently, the user can give more than two reviews. The ReviewMapping controller had a method so that all the users are assigned reviews automatically. Originally, the plan was to assign only a fixed number of reviews to each user. The dynamic review controller helped the review mapping controller assign reviews so that the reviews are never mapped such that the last user does not have any review to map, except his own. For example, consider three users, U1, U2 and U3. If U1 is assigned U2's work and U2 is assigned U1's work, U3 would not have any work to review. The dynamic review mapping controller makes sure that such a condition does not occur.

We were supposed to refactor these controllers. The ReportsController did not have any known use, and the DynamicReviewMapping Controller had changes to be made to make it conform to standards.

==Modification to Existing Code==

===ReportsController===
After searching through various controllers, looking for references used in the controller, we figured out that the code in the ReportsController was actually copied from the ResponseController, in December 2013. The ResponseController has been refactored since, and thus is an updated version. As of the usage, only the ResponseController has been referenced, and the ReportsController had never been used. We also extracted an older version of the ReportsController, that is, the one before it was replaced with code from the ResponseController. The code had a single method, and the method did not have any useful functionality. It was, thus, decided that the ReportsController should be removed from the Expertiza project, and that removing it would not have any effect on the overall project. Keeping it in would, on the other hand, create confusion for other people who would work on the project later.

===DynamicReviewMapping Controller===
*The code block between line 808 to 825 was duplicated in 3 places in this file. We have refactored the code to remove this bad smell. We have created a method called create_message to avoid duplication in the code.
*Method assign_metareviewers, assign_reviewers_team were too long. We have made two new methods (check_assignment_for_review and show_message_for_review_count) that does just one task and does it perfectly instead of large methods to do multiple tasks.
*Method assign_reviewers_individual was not used anymore. We have checked for its functionality and deleted it since it did not play any role in the final application.
*We have changed if to unless wherever necessary.
*Changed " == 0" expression to ".zero?"
*Used if (var) instead of if (var == true)
*We have used array checking and made changes according to the following rules:

**Use [].empty? instead of [].length == 0 or [].length.zero?
**Use [:foo].any? instead of [:foo].length > 0
**Use [:foo].one? instead of [:foo].length == 1
**Use [:foo].first instead of [:foo][0]
**Use [:foo].last instead of [:foo][-1]
*We have used && and || rather than and and or to keep boolean precedence.

None of this would actually change the functionality of the code. To make sure, we tried to look for the usage of the code. Again, after extensive searching, we figured that the code was never used. The DynamicReviewMapping controller, as stated above, depended on a set of rules that were not applicable anymore. The controller exists so that it is available, in case the rules are reverted to the original one. As such, currently the Controller is not used. We made the changes, but we have no way to check the code. We did the best we could, and we are sure that there are no errors in the refactored code.

==Further Reading==
*[http://www.refactoringinruby.com/ Refactoring In Ruby]
*[http://refactoring.com/ Refactoring]

==References==
<references/>

CSC/ECE 517 Fall 2014/oss E1457 ags

2014-11-06T03:01:22Z

Gshah: /* Refactoring in Ruby */

=Expertiza - Refactoring DynamicReviewMapping Controller and the ReportsController=

__TOC__

==Introduction==
It is time consuming to assess project work in a large classroom environment, and one of the best techniques to achieve this is to have students assist in this assessment. If each student is asked to assess a few (say, one to five) other students or student teams, the task requires a reasonable amount of effort; and that effort does not increase as the class gets larger. "''Expertiza is a system for managing all kinds of communication that is involved in assessment: double-blind communications between authors and reviewers, assessment of teammate contributions, evaluations by course staff, and surveys of students to assess the assignment and the
peer-review process.''" <ref>http://www.igi-global.com/book/monitoring-assessment-online-collaborative-environments/773&f=e-book</ref>
''"Expertiza project uses peer review to create reusable learning objects.''"<ref>http://expertiza.ncsu.edu/</ref> Students select from a list of tasks to be performed, with several students selecting each task. Then they prepare their work and submit it to an electronic peer-review system. The work is then reviewed by other students, who offer comments to help the submitters improve their work. The best submissions for each task are then selected for use in later courses. Expertiza gets students working together to improve others’ learning experiences. It helps them learn, by making them think through the lecture material and apply it to a real-world situation, just as they might do in an on-the-job situation. These learning objects can be improved iteratively; for example, the next year’s class can be presented with the examples developed by students the previous year, and asked to identify shortcomings and develop improved examples.<ref>http://scholar.google.com/scholar?q=%22Reusable+learning+objects+through+peer+review%3A+The+Expertiza+approach%22+%22The+Expertiza+platform+is+a+divide-and-conquer%22&btnG=&hl=en&as_sdt=0%2C34</ref> More information on Expertiza can be found [https://github.com/expertiza/expertiza here].

==Refactoring in Ruby==
Refactoring helps to<ref>http://www.refactoringinruby.com/</ref>
*Understand what led to poor code design
*Fix code which is difficult to understand
*Express each idea “once and only once”
*Recognize missing or inadequately formed classes
*Simplify overly complex relationships between classes
*Achieve the right balance of responsibilities among objects
*Make code easier to test and more maintainable

===Code Smells===
We identified the following categories of code smells in the helper module:

*Lengthy Definitions: These are the methods that have too many responsibilities and collaborators. As a result of which, their overall length has grown too long reducing the maintainability and readability.

*Duplicated Code: These are those pieces of code that does almost the same functionality of some other piece of code leading to a bad design style. They are usually too error prone since not everyone identifies all the code responsible for the same task and does the changes whenever the need arises.

*Bad method names: A good method name is expected to adhere to the Ruby style and design style guidelines. It is expected to convey a reasonable amount of responsibilities handled. A good method name in combination with good practices should resemble a user story.

*Used and unnecessary methods: These are those methods that were useful when the code was first developed. But, they lost their functionality as the code got updated and new functionalities were added or existing ones were modified.

===Refactoring Techniques===
There are many documented refactoring techniques, and a few common ones are below.<ref>http://www.integralist.co.uk/posts/refactoring-techniques/</ref>
*'''Rename Method''': Renaming identifiers can reduce the need for code comments and nearly always helps to promote greater clarity.
*'''Introduce Explaining Variable''': So here is a technique specifically based around the premise of renaming.
For example:
<pre>
unless "This is a String with some CAPS".scan(/([A-Z])/).empty?
puts "capitalised text was found"
end
</pre>
Should be:
<pre>
caps_not_found = "This is a String with some CAPS".scan(/([A-Z])/).empty?

unless caps_not_found
puts "capitalised text was found"
end
</pre>

*'''Extract Method''': It consists of breaking up long methods by shifting overly complex chunks of code into new methods which have very descriptive identifiers.
For example:
<pre>
class Foo
attr_reader :bar

def initialize bar
@bar = bar
end

def do_something
puts "my baz" # notice this is duplication
puts bar
end

def do_something_else
puts "my baz" # notice this is duplication
puts "Something else"
puts bar
end
end
</pre>

Becomes:
<pre>
class Foo
attr_reader :bar

def initialize bar
@bar = bar
end

def do_something
baz
puts bar
end

def do_something_else
baz
puts "Something else"
puts bar
end

def baz
puts "my baz"
end
end
</pre>

*'''Inline Method''': Sometimes you want the opposite of the Extract Method technique. Imagine a method exists whose content is already simple and clear, and whose identifier adds no extra benefit. So to fix this problem we'll convert the method invocation into an inlined piece of code.

*'''Pull Up Method''': When you have duplicated code across two separate classes then the best refactoring technique to implement is to pull that duplicate code up into a super class so we DRY (Don't Repeat Yourself) out the code and allow it to be used in multiple places without duplication (meaning changes in future only have to happen in one place).

For example:
<pre>
class Person
attr_reader :first_name, :last_name

def initialize first_name, last_name
@first_name = first_name
@last_name = last_name
end

end

class MalePerson < Person
# This is duplicated in the `FemalePerson` class
def full_name
first_name + " " + last_name
end

def gender
"M"
end
end

class FemalePerson < Person
# This is duplicated in the `MalePerson` class
def full_name
first_name + " " + last_name
end

def gender
"F"
end
end
</pre>
Becomes:
<pre>
class Person
attr_reader :first_name, :last_name

def initialize first_name, last_name
@first_name = first_name
@last_name = last_name
end

def full_name
first_name + " " + last_name
end
end

class MalePerson < Person
def gender
"M"
end
end

class FemalePerson < Person
def gender
"F"
end
end
</pre>

*'''Introduce Named Parameter''':When method arguments are unclear then convert them into named parameters so they become clearer (and easier to remember).

==Project Description==

We were supposed to refactor two controllers, the ReportsController and the DynamicReviewMapping Controller. The ReportsController was thought to be generating reports for students, showing all their scores in a single page. The DynamicReviewMapping Controller is actually a helper to the ReviewMapping controller. The review mapping controller maps reviews to each user. Currently, there are two ways to assign reviews to user: The user can either select a submission himself, which he wants to review, or the site can suggest a review to the user. Currently, the user can give more than two reviews. The ReviewMapping controller had a method so that all the users are assigned reviews automatically. Originally, the plan was to assign only a fixed number of reviews to each user. The dynamic review controller helped the review mapping controller assign reviews so that the reviews are never mapped such that the last user does not have any review to map, except his own. For example, consider three users, U1, U2 and U3. If U1 is assigned U2's work and U2 is assigned U1's work, U3 would not have any work to review. The dynamic review mapping controller makes sure that such a condition does not occur.

We were supposed to refactor these controllers. The ReportsController did not have any known use, and the DynamicReviewMapping Controller had changes to be made to make it conform to standards.

==Modification to Existing Code==

===ReportsController===
After searching through various controllers, looking for references used in the controller, we figured out that the code in the ReportsController was actually copied from the ResponseController, in December 2013. The ResponseController has been refactored since, and thus is an updated version. As of the usage, only the ResponseController has been referenced, and the ReportsController had never been used. We also extracted an older version of the ReportsController, that is, the one before it was replaced with code from the ResponseController. The code had a single method, and the method did not have any useful functionality. It was, thus, decided that the ReportsController should be removed from the Expertiza project, and that removing it would not have any effect on the overall project. Keeping it in would, on the other hand, create confusion for other people who would work on the project later.

===DynamicReviewMapping Controller===
The changes to be made to the DynamicReviewController were small ones:
*changing if to unless where applicable
*change the “== true" and "== false" wherever applicable
*A code block was repeated 3 times through the file. We were supposed to refactor that to a function to make the code DRYer.
*Methods assign_metareviewers and assign_reviewers_team were too long. We were supposed to break them up for better readability.
*Method assign_reviewers_individual did not seem to be used. We were supposed to make sure, then delete the method if that was the case.

None of this would actually change the functionality of the code. To make sure, we tried to look for the usage of the code. Again, after extensive searching, we figured that the code was never used. The DynamicReviewMapping controller, as stated above, depended on a set of rules that were not applicable anymore. The controller exists so that it is available, in case the rules are reverted to the original one. As such, currently the Controller is not used. We made the changes, but we have no way to check the code. We did the best we could, and we are sure that there are no errors in the refactored code.

==Further Reading==
*[http://www.refactoringinruby.com/ Refactoring In Ruby]
*[http://refactoring.com/ Refactoring]

==References==
<references/>

CSC/ECE 517 Fall 2014

2014-10-26T23:45:23Z

Gshah:

*[[CSC/ECE_517_Fall_2014/sample_page]]
*[[CSC/ECE_517_Fall_2014/ch1a 22 as]]
*[[CSC/ECE 517 Fall 2014/ch1a 19 mx]]
*[[CSC/ECE 517 Fall 2014/ch1a 3 zq]]
*[[CSC/ECE 517 Fall 2014/ch1a 4 lf]]
*[[CSC/ECE 517 Fall 2014/ch1a 4 wl]]
*[[CSC/ECE 517 Fall 2014/ch1a a7 ch]]
*[[CSC/ECE 517 Fall 2014/ch1a 25 rs]]
*[[CSC/ECE 517 Fall 2014/ch1a 25 jf]]
*[[CSC/ECE 517 Fall 2014/ch1a 8 os]]
*[[CSC/ECE 517 Fall 2014/ch1a 8 sn]]
*[[CSC/ECE 517 Fall 2014/ch1a 15 gs]]
*[[CSC/ECE 517 Fall 2014/ch1a 10 hu]]
*[[CSC/ECE 517 Fall 2014/ch1a 20 kv]]
*[[CSC/ECE 517 Fall 2014/ch1a 21 as]]
*[[CSC/ECE 517 Fall 2014/ch1a 24 sa]]
*[[CSC/ECE 517 Fall 2014/ch1a 26 sn]]
*[[CSC/ECE 517 Fall 2014/ch1a 6 rl]]
*[[CSC/ECE 517 Fall 2014/ch1a 2 ss]]
*[[CSC/ECE 517 Fall 2014/ch1a 16 av]]
*[[CSC/ECE 517 Fall 2014/ch1a 1 rm]]
*[[CSC/ECE 517 Fall 2014/ch1a 1 sj]]
*[[CSC/ECE 517 Fall 2014/ch1a 23 ss]]
*[[CSC/ECE 517 Fall 2014/ch1a 20 rn]]
*[[CSC/ECE 517 Fall 2014/ch1a 22 sp]]
*[[CSC/ECE 517 Fall 2014/ch1a 26 gn]]

*[[CSC/ECE 517 Fall 2014/ch1a 13 va]]
*[[CSC/ECE 517 Fall 2014/ch1a 9 aa]]
*[[CSC/ECE 517 Fall 2014/ch1a 9 kn]]
*[[CSC/ECE 517 Fall 2014/ch1a 11 ap]]
*[[CSC/ECE 517 Fall 2014/ch1a 25 ks]]
*[[CSC/ECE 517 Fall 2014/ch1a 7 kz]]
*[[CSC/ECE_517_Fall_2014/ch1a_6_bn]]
*[[CSC/ECE_517_Fall_2014/ch1a 10 zz]]
*[[CSC/ECE_517_Fall_2014/ch1a 16 va]]
*[[CSC/ECE_517_Fall_2014/ch1a F1415 rv]]
*[[CSC/ECE_517_Fall_2014/ch1a_3_cp]]
*[[CSC/ECE 517 Fall 2014/ch1b 26 sa]]
*[[CSC/ECE_517_Fall_2014/ch1b_28_cg]]
*[[CSC/ECE_517_Fall_2014/ch1b 29 ry]]
*[[CSC/ECE_517_Fall_2014/ch1b 30 cs]]
*[[CSC/ECE_517_Fall_2014/ch1b_33_jy]]
*[[CSC/ECE_517_Fall_2014/ch1b_27_js]]
*[[CSC/ECE 517 Fall 2014/oss E1465 oak]]
*[[CSC/ECE 517 Fall 2014/oss_M1456_kdv]]
*[[CSC/ECE 517 Fall 2014/oss_E1456_akk]]
*[[CSC/ECE_517_Fall_2014/oss_M1455_asa]]
*[[CSC/ECE_517_Fall_2014/oss_E1458_sst]]
*[[CSC/ECE_517_Fall_2014/oss_E1457_ags]]

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T04:27:44Z

Gshah: /* Comparison with other popular debugging tools */

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

Pry is written in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]<ref>http://en.wikipedia.org/wiki/Pry_(software)</ref>. The Pry core team consists of John Mair, Conrad Irwin and Ryan Fitzgerald and many more contributors. The last stable release was version 0.9.10 and it was released on July 15, 2012.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.A remote session allows you to start instances of Pry in a running program and connect to those instances over a socket. This is particularly useful for using Pry in places not normally possible, such as apps running on the Pow web server. It also opens the door for such exotica as multi-user sessions.

Pry has two plugins that implement remote sessions: 'pry-remote' and the newer and more ambitious 'pry-remote-em'<ref>https://github.com/Mon-Ouie/pry-remote</ref>.

'''pry-remote: '''A way to start Pry remotely and to connect to it using DRb. This allows to access the state of the running program from anywhere. Simply replace the normal 'binding.pry' call with 'binding.remote_pry' as the example below illustrates.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

We can then connect to it using the 'pry-remote' executable.

'''pry-remote-em: ''' pry-remote-em is a EventMachine-based alternative to pry-remote. It adds user authentication and SSL support along with tab completion and paging. It also allows multiple clients to connect to the same server, and multiple servers to run on the same computer and even within the same process.

require 'pry-remote-em/server'

<pre>
class Foo
def initialize(x, y)
binding.remote_pry_em
end
end

EM.run { Foo.new 10, 20 }
</pre>

= Comparison with other popular debugging tools =

Pry is a cross-over REPL because it supports some of what Ruby Debugger does with addons and sometimes even built and also supports all of what IRB does with some enhancements such as tab completion, code spacing and syntax highlighting as well as supporting an easy way to tap into an object with an REPL easily. There are also other things like the ability to show the source of a class, a method and source around where you are (if you are in a method)<ref>http://www.infoq.com/articles/ruby-debuggers-survey</ref>

Other debuggers available for Ruby are:

1.[http://en.wikipedia.org/wiki/Komodo_Edit Komodo]: The Komodo debugger is a tool for analyzing programs on a line-by-line basis, monitoring and altering variables, and watching output as it is generated.

2. Eclipse's [https://www.eclipse.org/proposals/dash/html/maintopic.html EclipseMonkey] extension allows scripts written in JRuby. As these scripts run inside the same JVM as the Eclipse IDE, it's possible to access the Debugger instances and control it.

3. [http://www.sapphiresteel.com SapphireSteel's] Ruby in Steel IDE is also built using native code to implement the functionality, complete with using Ruby hooks to get notified about events such as method invocations etc.

4. [http://en.wikipedia.org/wiki/RadRails Aptana RadRails]: Aptana RadRails sets breakpoints, inspect variables, control execution. The integrated Ruby & Rails debugger helps you squash the bugs.

5. [http://en.wikipedia.org/wiki/RubyMine RubyMine]: RubyMine has an excellent step-through debugger which lets you set breakpoints in your code and trace through the program. It provides a useful feature for exploring all of the metaprogramming going on behind the scenes in Ruby on Rails.

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T04:23:45Z

Gshah:

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

Pry is written in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]<ref>http://en.wikipedia.org/wiki/Pry_(software)</ref>. The Pry core team consists of John Mair, Conrad Irwin and Ryan Fitzgerald and many more contributors. The last stable release was version 0.9.10 and it was released on July 15, 2012.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.A remote session allows you to start instances of Pry in a running program and connect to those instances over a socket. This is particularly useful for using Pry in places not normally possible, such as apps running on the Pow web server. It also opens the door for such exotica as multi-user sessions.

Pry has two plugins that implement remote sessions: 'pry-remote' and the newer and more ambitious 'pry-remote-em'<ref>https://github.com/Mon-Ouie/pry-remote</ref>.

'''pry-remote: '''A way to start Pry remotely and to connect to it using DRb. This allows to access the state of the running program from anywhere. Simply replace the normal 'binding.pry' call with 'binding.remote_pry' as the example below illustrates.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

We can then connect to it using the 'pry-remote' executable.

'''pry-remote-em: ''' pry-remote-em is a EventMachine-based alternative to pry-remote. It adds user authentication and SSL support along with tab completion and paging. It also allows multiple clients to connect to the same server, and multiple servers to run on the same computer and even within the same process.

require 'pry-remote-em/server'

<pre>
class Foo
def initialize(x, y)
binding.remote_pry_em
end
end

EM.run { Foo.new 10, 20 }
</pre>

= Comparison with other popular debugging tools =

Pry is a cross-over REPL because it supports some of what Ruby Debugger does with addons and sometimes even built and also supports all of what IRB does with some enhancements such as tab completion, code spacing and syntax highlighting as well as supporting an easy way to tap into an object with an REPL easily. There are also other things like the ability to show the source of a class, a method and source around where you are (if you are in a method)<ref>http://www.infoq.com/articles/ruby-debuggers-survey</ref>

Other debuggers available for Ruby are:

1.[http://en.wikipedia.org/wiki/Komodo_Edit Komodo]: The Komodo debugger is a tool for analyzing programs on a line-by-line basis, monitoring and altering variables, and watching output as it is generated.

2. IDEs with embedded scripting support also allow to script the debugger. An option, for instance, is Eclipse's [https://www.eclipse.org/proposals/dash/html/maintopic.html EclipseMonkey] extension which allows scripts written in JRuby. As these scripts run inside the same JVM as the Eclipse IDE, it's possible to access the Debugger instances and control it.

3. [http://www.sapphiresteel.com SapphireSteel's] Ruby in Steel IDE is also built using native code to implement the functionality, complete with using Ruby hooks to get notified about events such as method invocations etc.

4. [http://en.wikipedia.org/wiki/RadRails Aptana RadRails]: Aptana RadRails sets breakpoints, inspect variables, control execution. The integrated Ruby & Rails debugger helps you squash the bugs.

5. [http://en.wikipedia.org/wiki/RubyMine RubyMine]: RubyMine has an excellent step-through debugger which lets you set breakpoints in your code and trace through the program. It provides a useful feature for exploring all of the metaprogramming going on behind the scenes in Ruby on Rails.

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T04:23:31Z

Gshah:

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

Pry is written in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]<ref>http://en.wikipedia.org/wiki/Pry_(software)</ref>. The Pry core team consists of John Mair, Conrad Irwin and Ryan Fitzgerald and many more contributors. The last stable release was version 0.9.10 and it was released on July 15, 2012.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.A remote session allows you to start instances of Pry in a running program and connect to those instances over a socket. This is particularly useful for using Pry in places not normally possible, such as apps running on the Pow web server. It also opens the door for such exotica as multi-user sessions.

Pry has two plugins that implement remote sessions: 'pry-remote' and the newer and more ambitious 'pry-remote-em'<ref>https://github.com/Mon-Ouie/pry-remote</ref>.

'''pry-remote: '''A way to start Pry remotely and to connect to it using DRb. This allows to access the state of the running program from anywhere. Simply replace the normal 'binding.pry' call with 'binding.remote_pry' as the example below illustrates.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

We can then connect to it using the 'pry-remote' executable.

'''pry-remote-em: ''' pry-remote-em is a EventMachine-based alternative to pry-remote. It adds user authentication and SSL support along with tab completion and paging. It also allows multiple clients to connect to the same server, and multiple servers to run on the same computer and even within the same process.

require 'pry-remote-em/server'

<pre>
class Foo
def initialize(x, y)
binding.remote_pry_em
end
end

EM.run { Foo.new 10, 20 }
</pre>

= Comparison with other popular debugging tools =

Pry is a cross-over REPL because it supports some of what Ruby Debugger does with addons and sometimes even built and also supports all of what IRB does with some enhancements such as tab completion, code spacing and syntax highlighting as well as supporting an easy way to tap into an object with an REPL easily. There are also other things like the ability to show the source of a class, a method and source around where you are (if you are in a method)<ref>http://www.infoq.com/articles/ruby-debuggers-survey</ref>

Other debuggers available for Ruby are:

1.[http://en.wikipedia.org/wiki/Komodo_Edit Komodo]: The Komodo debugger is a tool for analyzing programs on a line-by-line basis, monitoring and altering variables, and watching output as it is generated.

2. IDEs with embedded scripting support also allow to script the debugger. An option, for instance, is Eclipse's [https://www.eclipse.org/proposals/dash/html/maintopic.html EclipseMonkey] extension which allows scripts written in JRuby. As these scripts run inside the same JVM as the Eclipse IDE, it's possible to access the Debugger instances and control it.

3. [http://www.sapphiresteel.com SapphireSteel's] Ruby in Steel IDE is also built using native code to implement the functionality, complete with using Ruby hooks to get notified about events such as method invocations etc.

4. [http://en.wikipedia.org/wiki/RadRails Aptana RadRails]: Aptana RadRails sets breakpoints, inspect variables, control execution. The integrated Ruby & Rails debugger helps you squash the bugs.

5. [http://en.wikipedia.org/wiki/RubyMine RubyMine]: RubyMine has an excellent step-through debugger which lets you set breakpoints in your code and trace through the program. It provides a useful feature for exploring all of the metaprogramming going on behind the scenes in Ruby on Rails.

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T04:23:05Z

Gshah: /* Installation */

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

Pry is written in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]<ref>http://en.wikipedia.org/wiki/Pry_(software)</ref>. The Pry core team consists of John Mair, Conrad Irwin and Ryan Fitzgerald and many more contributors. The last stable release was version 0.9.10 and it was released on July 15, 2012.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.A remote session allows you to start instances of Pry in a running program and connect to those instances over a socket. This is particularly useful for using Pry in places not normally possible, such as apps running on the Pow web server. It also opens the door for such exotica as multi-user sessions.

Pry has two plugins that implement remote sessions: 'pry-remote' and the newer and more ambitious 'pry-remote-em'<ref>https://github.com/Mon-Ouie/pry-remote</ref>.

'''pry-remote: '''A way to start Pry remotely and to connect to it using DRb. This allows to access the state of the running program from anywhere. Simply replace the normal 'binding.pry' call with 'binding.remote_pry' as the example below illustrates.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

We can then connect to it using the 'pry-remote' executable.

'''pry-remote-em: ''' pry-remote-em is a EventMachine-based alternative to pry-remote. It adds user authentication and SSL support along with tab completion and paging. It also allows multiple clients to connect to the same server, and multiple servers to run on the same computer and even within the same process.

require 'pry-remote-em/server'

<pre>
class Foo
def initialize(x, y)
binding.remote_pry_em
end
end

EM.run { Foo.new 10, 20 }
</pre>

= Comparison with other popular debugging tools =

Pry is a cross-over REPL because it supports some of what Ruby Debugger does with addons and sometimes even built and also supports all of what IRB does with some enhancements such as tab completion, code spacing and syntax highlighting as well as supporting an easy way to tap into an object with an REPL easily. There are also other things like the ability to show the source of a class, a method and source around where you are (if you are in a method)<ref>http://www.infoq.com/articles/ruby-debuggers-survey</ref>

Other debuggers available for Ruby are:

1.[http://en.wikipedia.org/wiki/Komodo_Edit Komodo]: The Komodo debugger is a tool for analyzing programs on a line-by-line basis, monitoring and altering variables, and watching output as it is generated.

2. IDEs with embedded scripting support also allow to script the debugger. An option, for instance, is Eclipse's [https://www.eclipse.org/proposals/dash/html/maintopic.html EclipseMonkey] extension which allows scripts written in JRuby. As these scripts run inside the same JVM as the Eclipse IDE, it's possible to access the Debugger instances and control it.

3. [http://www.sapphiresteel.com SapphireSteel's] Ruby in Steel IDE is also built using native code to implement the functionality, complete with using Ruby hooks to get notified about events such as method invocations etc.

4. [http://en.wikipedia.org/wiki/RadRails Aptana RadRails]: Aptana RadRails sets breakpoints, inspect variables, control execution. The integrated Ruby & Rails debugger helps you squash the bugs.

5. [http://en.wikipedia.org/wiki/RubyMine RubyMine]: RubyMine has an excellent step-through debugger which lets you set breakpoints in your code and trace through the program. It provides a useful feature for exploring all of the metaprogramming going on behind the scenes in Ruby on Rails.

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T04:22:43Z

Gshah: /* See also */

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

Pry is written in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]<ref>http://en.wikipedia.org/wiki/Pry_(software)</ref>. The Pry core team consists of John Mair, Conrad Irwin and Ryan Fitzgerald and many more contributors. The last stable release was version 0.9.10 and it was released on July 15, 2012.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.A remote session allows you to start instances of Pry in a running program and connect to those instances over a socket. This is particularly useful for using Pry in places not normally possible, such as apps running on the Pow web server. It also opens the door for such exotica as multi-user sessions.

Pry has two plugins that implement remote sessions: 'pry-remote' and the newer and more ambitious 'pry-remote-em'<ref>https://github.com/Mon-Ouie/pry-remote</ref>.

'''pry-remote: '''A way to start Pry remotely and to connect to it using DRb. This allows to access the state of the running program from anywhere. Simply replace the normal 'binding.pry' call with 'binding.remote_pry' as the example below illustrates.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

We can then connect to it using the 'pry-remote' executable.

'''pry-remote-em: ''' pry-remote-em is a EventMachine-based alternative to pry-remote. It adds user authentication and SSL support along with tab completion and paging. It also allows multiple clients to connect to the same server, and multiple servers to run on the same computer and even within the same process.

require 'pry-remote-em/server'

<pre>
class Foo
def initialize(x, y)
binding.remote_pry_em
end
end

EM.run { Foo.new 10, 20 }
</pre>

= Comparison with other popular debugging tools =

Pry is a cross-over REPL because it supports some of what Ruby Debugger does with addons and sometimes even built and also supports all of what IRB does with some enhancements such as tab completion, code spacing and syntax highlighting as well as supporting an easy way to tap into an object with an REPL easily. There are also other things like the ability to show the source of a class, a method and source around where you are (if you are in a method)<ref>http://www.infoq.com/articles/ruby-debuggers-survey</ref>

Other debuggers available for Ruby are:

1.[http://en.wikipedia.org/wiki/Komodo_Edit Komodo]: The Komodo debugger is a tool for analyzing programs on a line-by-line basis, monitoring and altering variables, and watching output as it is generated.

2. IDEs with embedded scripting support also allow to script the debugger. An option, for instance, is Eclipse's [https://www.eclipse.org/proposals/dash/html/maintopic.html EclipseMonkey] extension which allows scripts written in JRuby. As these scripts run inside the same JVM as the Eclipse IDE, it's possible to access the Debugger instances and control it.

3. [http://www.sapphiresteel.com SapphireSteel's] Ruby in Steel IDE is also built using native code to implement the functionality, complete with using Ruby hooks to get notified about events such as method invocations etc.

4. [http://en.wikipedia.org/wiki/RadRails Aptana RadRails]: Aptana RadRails sets breakpoints, inspect variables, control execution. The integrated Ruby & Rails debugger helps you squash the bugs.

5. [http://en.wikipedia.org/wiki/RubyMine RubyMine]: RubyMine has an excellent step-through debugger which lets you set breakpoints in your code and trace through the program. It provides a useful feature for exploring all of the metaprogramming going on behind the scenes in Ruby on Rails.

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T04:22:17Z

Gshah: /* Comparison with other popular debugging tools */

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

Pry is written in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]<ref>http://en.wikipedia.org/wiki/Pry_(software)</ref>. The Pry core team consists of John Mair, Conrad Irwin and Ryan Fitzgerald and many more contributors. The last stable release was version 0.9.10 and it was released on July 15, 2012.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.A remote session allows you to start instances of Pry in a running program and connect to those instances over a socket. This is particularly useful for using Pry in places not normally possible, such as apps running on the Pow web server. It also opens the door for such exotica as multi-user sessions.

Pry has two plugins that implement remote sessions: 'pry-remote' and the newer and more ambitious 'pry-remote-em'<ref>https://github.com/Mon-Ouie/pry-remote</ref>.

'''pry-remote: '''A way to start Pry remotely and to connect to it using DRb. This allows to access the state of the running program from anywhere. Simply replace the normal 'binding.pry' call with 'binding.remote_pry' as the example below illustrates.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

We can then connect to it using the 'pry-remote' executable.

'''pry-remote-em: ''' pry-remote-em is a EventMachine-based alternative to pry-remote. It adds user authentication and SSL support along with tab completion and paging. It also allows multiple clients to connect to the same server, and multiple servers to run on the same computer and even within the same process.

require 'pry-remote-em/server'

<pre>
class Foo
def initialize(x, y)
binding.remote_pry_em
end
end

EM.run { Foo.new 10, 20 }
</pre>

= Comparison with other popular debugging tools =

Pry is a cross-over REPL because it supports some of what Ruby Debugger does with addons and sometimes even built and also supports all of what IRB does with some enhancements such as tab completion, code spacing and syntax highlighting as well as supporting an easy way to tap into an object with an REPL easily. There are also other things like the ability to show the source of a class, a method and source around where you are (if you are in a method)<ref>http://www.infoq.com/articles/ruby-debuggers-survey</ref>

Other debuggers available for Ruby are:

1.[http://en.wikipedia.org/wiki/Komodo_Edit Komodo]: The Komodo debugger is a tool for analyzing programs on a line-by-line basis, monitoring and altering variables, and watching output as it is generated.

2. IDEs with embedded scripting support also allow to script the debugger. An option, for instance, is Eclipse's [https://www.eclipse.org/proposals/dash/html/maintopic.html EclipseMonkey] extension which allows scripts written in JRuby. As these scripts run inside the same JVM as the Eclipse IDE, it's possible to access the Debugger instances and control it.

3. [http://www.sapphiresteel.com SapphireSteel's] Ruby in Steel IDE is also built using native code to implement the functionality, complete with using Ruby hooks to get notified about events such as method invocations etc.

4. [http://en.wikipedia.org/wiki/RadRails Aptana RadRails]: Aptana RadRails sets breakpoints, inspect variables, control execution. The integrated Ruby & Rails debugger helps you squash the bugs.

5. [http://en.wikipedia.org/wiki/RubyMine RubyMine]: RubyMine has an excellent step-through debugger which lets you set breakpoints in your code and trace through the program. It provides a useful feature for exploring all of the metaprogramming going on behind the scenes in Ruby on Rails.

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T04:08:46Z

Gshah: /* Comparison with other popular debugging tools */

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

Pry is written in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]<ref>http://en.wikipedia.org/wiki/Pry_(software)</ref>. The Pry core team consists of John Mair, Conrad Irwin and Ryan Fitzgerald and many more contributors. The last stable release was version 0.9.10 and it was released on July 15, 2012.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.A remote session allows you to start instances of Pry in a running program and connect to those instances over a socket. This is particularly useful for using Pry in places not normally possible, such as apps running on the Pow web server. It also opens the door for such exotica as multi-user sessions.

Pry has two plugins that implement remote sessions: 'pry-remote' and the newer and more ambitious 'pry-remote-em'<ref>https://github.com/Mon-Ouie/pry-remote</ref>.

'''pry-remote: '''A way to start Pry remotely and to connect to it using DRb. This allows to access the state of the running program from anywhere. Simply replace the normal 'binding.pry' call with 'binding.remote_pry' as the example below illustrates.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

We can then connect to it using the 'pry-remote' executable.

'''pry-remote-em: ''' pry-remote-em is a EventMachine-based alternative to pry-remote. It adds user authentication and SSL support along with tab completion and paging. It also allows multiple clients to connect to the same server, and multiple servers to run on the same computer and even within the same process.

require 'pry-remote-em/server'

<pre>
class Foo
def initialize(x, y)
binding.remote_pry_em
end
end

EM.run { Foo.new 10, 20 }
</pre>

= Comparison with other popular debugging tools =

Pry is a cross-over REPL because it supports some of what Ruby Debugger does with addons and sometimes even built and also supports all of what IRB does with some enhancements such as tab completion, code spacing and syntax highlighting as well as supporting an easy way to tap into an object with an REPL easily. There are also other things like the ability to show the source of a class, a method and source around where you are (if you are in a method)<ref>http://www.infoq.com/articles/ruby-debuggers-survey</ref>

Other debuggers available for Ruby are:

1. http://en.wikipedia.org/wiki/Komodo_Edit
2. IDEs with embedded scripting support also allow to script the debugger. An option, for instance, is Eclipse's EclipseMonkey extension which allows scripts written in JRuby. As these scripts run inside the same JVM as the Eclipse IDE, it's possible to access the Debugger instances and control it.

3. SapphireSteel's Ruby in Steel IDE is also built using native code to implement the functionality, complete with using Ruby hooks to get notified about events such as method invocations etc.

4. Komodo can debug Ruby

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T03:59:11Z

Gshah: /* Comparison with other popular debugging tools */

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

Pry is written in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]<ref>http://en.wikipedia.org/wiki/Pry_(software)</ref>. The Pry core team consists of John Mair, Conrad Irwin and Ryan Fitzgerald and many more contributors. The last stable release was version 0.9.10 and it was released on July 15, 2012.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.A remote session allows you to start instances of Pry in a running program and connect to those instances over a socket. This is particularly useful for using Pry in places not normally possible, such as apps running on the Pow web server. It also opens the door for such exotica as multi-user sessions.

Pry has two plugins that implement remote sessions: 'pry-remote' and the newer and more ambitious 'pry-remote-em'<ref>https://github.com/Mon-Ouie/pry-remote</ref>.

'''pry-remote: '''A way to start Pry remotely and to connect to it using DRb. This allows to access the state of the running program from anywhere. Simply replace the normal 'binding.pry' call with 'binding.remote_pry' as the example below illustrates.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

We can then connect to it using the 'pry-remote' executable.

'''pry-remote-em: ''' pry-remote-em is a EventMachine-based alternative to pry-remote. It adds user authentication and SSL support along with tab completion and paging. It also allows multiple clients to connect to the same server, and multiple servers to run on the same computer and even within the same process.

require 'pry-remote-em/server'

<pre>
class Foo
def initialize(x, y)
binding.remote_pry_em
end
end

EM.run { Foo.new 10, 20 }
</pre>

= Comparison with other popular debugging tools =

Pry is a cross-over REPL because it supports some of what Ruby Debugger does with addons and sometimes even built and also supports all of what IRB does with some enhancements such as tab completion, code spacing and syntax highlighting as well as supporting an easy way to tap into an object with an REPL easily. There are also other things like the ability to show the source of a class, a method and source around where you are (if you are in a method)<ref>http://www.infoq.com/articles/ruby-debuggers-survey</ref>

Other debuggers available for Ruby are:

1. Command line interfaces for Ruby debuggers are available, such as the one shipped with the Ruby standard library, the Rubinius debugger. While these certainly allow to debug code, they also make it quite tedious to set breakpoints or see what's actually going on. Rubinius debugger uses accessible and modifiable opcodes of the Ruby code. A breakpoint is set by exchanging a regular opcode with a special opcode that suspends the current thread and notifies the higher layers of the debugger stack.

2. IDEs with embedded scripting support also allow to script the debugger. An option, for instance, is Eclipse's EclipseMonkey extension which allows scripts written in JRuby. As these scripts run inside the same JVM as the Eclipse IDE, it's possible to access the Debugger instances and control it.

3. SapphireSteel's Ruby in Steel IDE is also built using native code to implement the functionality, complete with using Ruby hooks to get notified about events such as method invocations etc.

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T03:28:45Z

Gshah: /* Remote debugging */

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

Pry is written in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]<ref>http://en.wikipedia.org/wiki/Pry_(software)</ref>. The Pry core team consists of John Mair, Conrad Irwin and Ryan Fitzgerald and many more contributors. The last stable release was version 0.9.10 and it was released on July 15, 2012.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.A remote session allows you to start instances of Pry in a running program and connect to those instances over a socket. This is particularly useful for using Pry in places not normally possible, such as apps running on the Pow web server. It also opens the door for such exotica as multi-user sessions.

Pry has two plugins that implement remote sessions: 'pry-remote' and the newer and more ambitious 'pry-remote-em'<ref>https://github.com/Mon-Ouie/pry-remote</ref>.

'''pry-remote: '''A way to start Pry remotely and to connect to it using DRb. This allows to access the state of the running program from anywhere. Simply replace the normal 'binding.pry' call with 'binding.remote_pry' as the example below illustrates.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

We can then connect to it using the 'pry-remote' executable.

'''pry-remote-em: ''' pry-remote-em is a EventMachine-based alternative to pry-remote. It adds user authentication and SSL support along with tab completion and paging. It also allows multiple clients to connect to the same server, and multiple servers to run on the same computer and even within the same process.

require 'pry-remote-em/server'

<pre>
class Foo
def initialize(x, y)
binding.remote_pry_em
end
end

EM.run { Foo.new 10, 20 }
</pre>

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T03:26:00Z

Gshah: /* Remote debugging */

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

Pry is written in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]<ref>http://en.wikipedia.org/wiki/Pry_(software)</ref>. The Pry core team consists of John Mair, Conrad Irwin and Ryan Fitzgerald and many more contributors. The last stable release was version 0.9.10 and it was released on July 15, 2012.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.A remote session allows you to start instances of Pry in a running program and connect to those instances over a socket. This is particularly useful for using Pry in places not normally possible, such as apps running on the Pow web server. It also opens the door for such exotica as multi-user sessions.

Pry has two plugins that implement remote sessions: 'pry-remote' and the newer and more ambitious 'pry-remote-em'.

'''pry-remote: '''A way to start Pry remotely and to connect to it using DRb. This allows to access the state of the running program from anywhere. Simply replace the normal 'binding.pry' call with 'binding.remote_pry' as the example below illustrates.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

We can then connect to it using the 'pry-remote' executable.

'''pry-remote-em: ''' pry-remote-em is a EventMachine-based alternative to pry-remote. It adds user authentication and SSL support along with tab completion and paging. It also allows multiple clients to connect to the same server, and multiple servers to run on the same computer and even within the same process.

require 'pry-remote-em/server'

<pre>
class Foo
def initialize(x, y)
binding.remote_pry_em
end
end

EM.run { Foo.new 10, 20 }
</pre>

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T03:22:25Z

Gshah: /* Remote debugging */

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

Pry is written in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]<ref>http://en.wikipedia.org/wiki/Pry_(software)</ref>. The Pry core team consists of John Mair, Conrad Irwin and Ryan Fitzgerald and many more contributors. The last stable release was version 0.9.10 and it was released on July 15, 2012.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.A remote session allows you to start instances of Pry in a running program and connect to those instances over a socket. This is particularly useful for using Pry in places not normally possible, such as apps running on the Pow web server. It also opens the door for such exotica as multi-user sessions.

Pry has two plugins that implement remote sessions: 'pry-remote' and the newer and more ambitious 'pry-remote-em'.

'''pry-remote: '''A way to start Pry remotely and to connect to it using DRb. This allows to access the state of the running program from anywhere. Simply replace the normal 'binding.pry' call with 'binding.remote_pry' as the example below illustrates.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

We can then connect to it using the 'pry-remote' executable.

'''pry-remote-em: '''

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T03:13:50Z

Gshah:

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

Pry is written in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]<ref>http://en.wikipedia.org/wiki/Pry_(software)</ref>. The Pry core team consists of John Mair, Conrad Irwin and Ryan Fitzgerald and many more contributors. The last stable release was version 0.9.10 and it was released on July 15, 2012.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.Pry-remote (along with its cousin pry-remote-em) enables you to start instances of Pry in a running program and connect to those instances over a network or the Internet. Once connected you can interact with the internal state of the program. This plugin comes into its own when used with tools such as Pow, enabling you to get a Pry session in places not normally possible. pry-remote is also notable for having pry-nav support.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T03:13:37Z

Gshah:

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|thumb]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

Pry is written in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]<ref>http://en.wikipedia.org/wiki/Pry_(software)</ref>. The Pry core team consists of John Mair, Conrad Irwin and Ryan Fitzgerald and many more contributors. The last stable release was version 0.9.10 and it was released on July 15, 2012.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.Pry-remote (along with its cousin pry-remote-em) enables you to start instances of Pry in a running program and connect to those instances over a network or the Internet. Once connected you can interact with the internal state of the program. This plugin comes into its own when used with tools such as Pow, enabling you to get a Pry session in places not normally possible. pry-remote is also notable for having pry-nav support.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T03:13:12Z

Gshah:

<big>'''Debugging in Rails using Pry'''</big>

<ref>http://pryrepl.org</ref>[[File:Pry REPL Logo.png|right]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

Pry is written in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]<ref>http://en.wikipedia.org/wiki/Pry_(software)</ref>. The Pry core team consists of John Mair, Conrad Irwin and Ryan Fitzgerald and many more contributors. The last stable release was version 0.9.10 and it was released on July 15, 2012.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.Pry-remote (along with its cousin pry-remote-em) enables you to start instances of Pry in a running program and connect to those instances over a network or the Internet. Once connected you can interact with the internal state of the program. This plugin comes into its own when used with tools such as Pow, enabling you to get a Pry session in places not normally possible. pry-remote is also notable for having pry-nav support.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T03:12:32Z

Gshah:

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right]]<ref>http://pryrepl.org</ref>
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

Pry is written in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]<ref>http://en.wikipedia.org/wiki/Pry_(software)</ref>. The Pry core team consists of John Mair, Conrad Irwin and Ryan Fitzgerald and many more contributors. The last stable release was version 0.9.10 and it was released on July 15, 2012.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.Pry-remote (along with its cousin pry-remote-em) enables you to start instances of Pry in a running program and connect to those instances over a network or the Internet. Once connected you can interact with the internal state of the program. This plugin comes into its own when used with tools such as Pow, enabling you to get a Pry session in places not normally possible. pry-remote is also notable for having pry-nav support.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T03:10:24Z

Gshah:

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right|Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

Pry is written in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]<ref>http://en.wikipedia.org/wiki/Pry_(software)</ref>. The Pry core team consists of John Mair, Conrad Irwin and Ryan Fitzgerald and many more contributors. The last stable release was version 0.9.10 and it was released on July 15, 2012.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.Pry-remote (along with its cousin pry-remote-em) enables you to start instances of Pry in a running program and connect to those instances over a network or the Internet. Once connected you can interact with the internal state of the program. This plugin comes into its own when used with tools such as Pow, enabling you to get a Pry session in places not normally possible. pry-remote is also notable for having pry-nav support.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T03:09:04Z

Gshah:

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right|Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

Pry is written in Ruby<ref>http://en.wikipedia.org/wiki/Pry_(software)</ref>. The Pry core team consists of John Mair, Conrad Irwin and Ryan Fitzgerald and many more contributors. The last stable release was version 0.9.10 and it was released on July 15, 2012.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.Pry-remote (along with its cousin pry-remote-em) enables you to start instances of Pry in a running program and connect to those instances over a network or the Internet. Once connected you can interact with the internal state of the program. This plugin comes into its own when used with tools such as Pow, enabling you to get a Pry session in places not normally possible. pry-remote is also notable for having pry-nav support.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T03:07:34Z

Gshah:

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right|Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

Pry is written in Ruby<ref>http://en.wikipedia.org/wiki/Pry_(software)#Competitors</ref>. The Pry core team consists of John Mair, Conrad Irwin and Ryan Fitzgerald and many more contributors. The last stable release was version 0.9.10 and it was released on July 15, 2012.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.Pry-remote (along with its cousin pry-remote-em) enables you to start instances of Pry in a running program and connect to those instances over a network or the Internet. Once connected you can interact with the internal state of the program. This plugin comes into its own when used with tools such as Pow, enabling you to get a Pry session in places not normally possible. pry-remote is also notable for having pry-nav support.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T02:21:12Z

Gshah: /* Remote debugging */

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right|Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

Remote debugging means you work on your local computer and you want to start and debug a program on another computer, the remote machine. Pry is a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it.Pry-remote (along with its cousin pry-remote-em) enables you to start instances of Pry in a running program and connect to those instances over a network or the Internet. Once connected you can interact with the internal state of the program. This plugin comes into its own when used with tools such as Pow, enabling you to get a Pry session in places not normally possible. pry-remote is also notable for having pry-nav support.

We set up the server as follows:
<pre>
require 'pry-remote'

class Foo
def initialize(x, y)
binding.remote_pry
end
end

Foo.new 10, 20
</pre>

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T01:10:58Z

Gshah:

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right|Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]<ref>https://github.com/jnicklas/capybara</ref>), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T01:07:33Z

Gshah:

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right|Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
,[http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
https://github.com/jnicklas/capybara
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T01:03:50Z

Gshah: /* Features */

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right|Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
, [http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# [http://en.wikipedia.org/wiki/Rubinius Rubinius] core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T01:01:22Z

Gshah:

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right|Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a [http://en.wikipedia.org/wiki/Web_application Web application] framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the [http://en.wikipedia.org/wiki/Model–view–controller model view controller], like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP]-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
, [http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring [http://en.wikipedia.org/wiki/Read–eval–print_loop REPL] driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# [http://en.wikipedia.org/wiki/GitHub#Gist Gist] integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by [http://en.wikipedia.org/wiki/IPython IPython], [http://en.wikipedia.org/wiki/Smalltalk Smalltalk] and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T00:50:46Z

Gshah:

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right|Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a Web application framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the model view controller, like Mailers, Routes ([http://en.wikipedia.org/wiki/Representational_state_transfer REST], HTTP-Verbs, Constraints), Environments and Initializers, Caching ([http://en.wikipedia.org/wiki/Representational_state_transfer Redis]
, [http://en.wikipedia.org/wiki/Memcached Memcached]), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. [http://en.wikipedia.org/wiki/Debugging Debugging] is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell IRB] shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features [http://en.wikipedia.org/wiki/Syntax_highlighting Syntax highlighting], a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration - and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring REPL driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# Gist integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by IPython, Smalltalk and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T00:43:42Z

Gshah:

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right|Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a Web application framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the model view controller, like Mailers, Routes (REST, HTTP-Verbs, Constraints), Environments and Initializers, Caching (Redis, Memcached), Assets ([http://en.wikipedia.org/wiki/Cascading_Style_Sheets CSS], [http://en.wikipedia.org/wiki/Sass_(stylesheet_language) SASS], [http://en.wikipedia.org/wiki/JavaScript Javascript], [http://en.wikipedia.org/wiki/CoffeeScript CoffeeScript], [http://en.wikipedia.org/wiki/Pipeline_(computing) Pipelining]), Bundler and dependency management, Tests ([http://en.wikipedia.org/wiki/RSpec RSpec] , [https://github.com/jnicklas/capybara Capybara]), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. Debugging is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard IRB shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features syntax highlighting, a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration- and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring REPL driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# Gist integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by IPython, Smalltalk and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T00:34:39Z

Gshah:

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right|Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a Web application framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the model view controller, like Mailers, Routes (REST, HTTP-Verbs, Constraints), Environments and Initializers, Caching (Redis, Memcached), Assets (CSS, SASS,, JavaScript, CoffeeScript, Pipelining), Bundler and dependency management, Tests (RSpec, Capybara), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. Debugging is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard IRB shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features syntax highlighting, a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration- and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring REPL driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# Gist integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by IPython, Smalltalk and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T00:34:12Z

Gshah:

<big>'''Debugging in Rails using Pry'''</big>

[[File:Pry REPL Logo.png|right|Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a Web application framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the model view controller, like Mailers, Routes (REST, HTTP-Verbs, Constraints), Environments and Initializers, Caching (Redis, Memcached), Assets (CSS, SASS,, JavaScript, CoffeeScript, Pipelining), Bundler and dependency management, Tests (RSpec, Capybara), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. Debugging is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard IRB shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features syntax highlighting, a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration- and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

__TOC__

= Introduction =

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring REPL driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# Gist integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by IPython, Smalltalk and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T00:33:23Z

Gshah:

<big>'''Debugging in Rails using Pry'''</big>

__TOC__

= Introduction =

[[File:Pry REPL Logo.png|right|Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a Web application framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the model view controller, like Mailers, Routes (REST, HTTP-Verbs, Constraints), Environments and Initializers, Caching (Redis, Memcached), Assets (CSS, SASS,, JavaScript, CoffeeScript, Pipelining), Bundler and dependency management, Tests (RSpec, Capybara), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. Debugging is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard IRB shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features syntax highlighting, a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration- and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring REPL driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# Gist integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by IPython, Smalltalk and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T00:31:50Z

Gshah:

'''Debugging in Rails using Pry'''

__TOC__

= Introduction =

[[File:Pry REPL Logo.png|right|alt=Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a Web application framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the model view controller, like Mailers, Routes (REST, HTTP-Verbs, Constraints), Environments and Initializers, Caching (Redis, Memcached), Assets (CSS, SASS,, JavaScript, CoffeeScript, Pipelining), Bundler and dependency management, Tests (RSpec, Capybara), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. Debugging is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard IRB shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features syntax highlighting, a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration- and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring REPL driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# Gist integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by IPython, Smalltalk and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T00:30:37Z

Gshah:

= Debugging in Rails using Pry =

__TOC__

= Introduction =

[[File:Pry REPL Logo.png|right|alt=Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a Web application framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the model view controller, like Mailers, Routes (REST, HTTP-Verbs, Constraints), Environments and Initializers, Caching (Redis, Memcached), Assets (CSS, SASS,, JavaScript, CoffeeScript, Pipelining), Bundler and dependency management, Tests (RSpec, Capybara), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. Debugging is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard IRB shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features syntax highlighting, a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration- and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring REPL driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# Gist integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by IPython, Smalltalk and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T00:30:16Z

Gshah:

Debugging in Rails using Pry

__TOC__

= Introduction =

[[File:Pry REPL Logo.png|right|alt=Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a Web application framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the model view controller, like Mailers, Routes (REST, HTTP-Verbs, Constraints), Environments and Initializers, Caching (Redis, Memcached), Assets (CSS, SASS,, JavaScript, CoffeeScript, Pipelining), Bundler and dependency management, Tests (RSpec, Capybara), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. Debugging is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard IRB shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features syntax highlighting, a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration- and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring REPL driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features ====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# Gist integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by IPython, Smalltalk and other advanced REPLs

= Installation =

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

= Usage and Example =

=== Usage ===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

=== Example ===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

= Pry Commands =

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

= Remote debugging =

= Comparison with other popular debugging tools =

= See also =

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

= References =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-26T00:15:45Z

Gshah:

__TOC__

= Introduction =

[[File:Pry REPL Logo.png|right|alt=Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a Web application framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the model view controller, like Mailers, Routes (REST, HTTP-Verbs, Constraints), Environments and Initializers, Caching (Redis, Memcached), Assets (CSS, SASS,, JavaScript, CoffeeScript, Pipelining), Bundler and dependency management, Tests (RSpec, Capybara), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. Debugging is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard IRB shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features syntax highlighting, a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration- and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring REPL driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# Gist integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by IPython, Smalltalk and other advanced REPLs

= Installation=

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

=Usage and Example=

===Usage===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

===Example===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

=Pry Commands=

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

=Remote debugging=

=Comparison with other popular debugging tools=

=See also=

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

=References=
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-20T04:07:30Z

Gshah: /* Example */

__TOC__

= Introduction =

[[File:Pry REPL Logo.png|right|alt=Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a Web application framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the model view controller, like Mailers, Routes (REST, HTTP-Verbs, Constraints), Environments and Initializers, Caching (Redis, Memcached), Assets (CSS, SASS,, JavaScript, CoffeeScript, Pipelining), Bundler and dependency management, Tests (RSpec, Capybara), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. Debugging is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard IRB shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features syntax highlighting, a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration- and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring REPL driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# Gist integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by IPython, Smalltalk and other advanced REPLs

= Installation=

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

=Usage and Example=

===Usage===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

===Example===
For example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

=Pry Commands=

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

=See also=

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

=References=
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-20T04:06:12Z

Gshah: /* Pry Commands */

__TOC__

= Introduction =

[[File:Pry REPL Logo.png|right|alt=Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a Web application framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the model view controller, like Mailers, Routes (REST, HTTP-Verbs, Constraints), Environments and Initializers, Caching (Redis, Memcached), Assets (CSS, SASS,, JavaScript, CoffeeScript, Pipelining), Bundler and dependency management, Tests (RSpec, Capybara), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. Debugging is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard IRB shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features syntax highlighting, a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration- and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring REPL driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# Gist integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by IPython, Smalltalk and other advanced REPLs

= Installation=

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

=Usage and Example=

===Usage===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

===Example===
Fr example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

=Pry Commands=

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

::''Description'': Shows more information (doc) about an object, or method

:4. cat <File>

::''Description'': Display the content of a file

:5. _file_

::''Description'': Represent the last file Pry touched

:6. wtf?

::''Description'': Print the stack trace, same as _ex_.backtrace

:7. $

::''Description'': Show source, shortcut for show-source

:8. edit <Method>

::''Description'': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

::''Description'': Search history

:10. _out_

::''Description'': Array of all outputs values, also _in_

:11. cd <var>

::''Description'': Step into an object, change the value of self

:12. cd ..

::''Description'': Take out of a level

:13. binding.pry

::''Description'': Breakpoint

:14. edit --ex

::''Description'': Edit the file where the last exception was thrown

:15. .<Shell>

::''Description'': Runs the <Shell> command

:16. whereami

::''Description'': Print the context where the debugger is stopped

:17. ;

::''Description'': Would mute the return output by Ruby

:18. play -l

::''Description'': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

=See also=

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

=References=
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-20T04:04:13Z

Gshah: /* Pry Commands */

__TOC__

= Introduction =

[[File:Pry REPL Logo.png|right|alt=Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a Web application framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the model view controller, like Mailers, Routes (REST, HTTP-Verbs, Constraints), Environments and Initializers, Caching (Redis, Memcached), Assets (CSS, SASS,, JavaScript, CoffeeScript, Pipelining), Bundler and dependency management, Tests (RSpec, Capybara), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. Debugging is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard IRB shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features syntax highlighting, a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration- and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring REPL driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# Gist integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by IPython, Smalltalk and other advanced REPLs

= Installation=

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

=Usage and Example=

===Usage===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

===Example===
Fr example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

=Pry Commands=

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

::''Description'': It show all of the available methods that can be called by an object

:2. _

::''Description'': Last output

:3. ? <Object>

:'''Description''': Shows more information (doc) about an object, or method

:4. cat <File>

:'''Description''': Display the content of a file

:5. _file_

:'''Description''': Represent the last file Pry touched

:6. wtf?

:'''Description''': Print the stack trace, same as _ex_.backtrace

:7. $

:'''Description''': Show source, shortcut for show-source

:8. edit <Method>

:'''Description''': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

:'''Description''': Search history

:10. _out_

:'''Description''': Array of all outputs values, also _in_

:11. cd <var>

:'''Description''': Step into an object, change the value of self

:12. cd ..

:'''Description''': Take out of a level

:13. binding.pry

:'''Description''': Breakpoint

:14. edit --ex

:'''Description''': Edit the file where the last exception was thrown

:15. .<Shell>

:'''Description''': Runs the <Shell> command

:16. whereami

:'''Description''': Print the context where the debugger is stopped

:17. ;

:'''Description''': Would mute the return output by Ruby

:18. play -l

:'''Description''': Execute the line in the current debugging context

:The best thing to do is just type help once you've installed pry.

=See also=

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

=References=
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-20T03:51:28Z

Gshah: /* Introduction */

__TOC__

= Introduction =

[[File:Pry REPL Logo.png|right|alt=Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a Web application framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the model view controller, like Mailers, Routes (REST, HTTP-Verbs, Constraints), Environments and Initializers, Caching (Redis, Memcached), Assets (CSS, SASS,, JavaScript, CoffeeScript, Pipelining), Bundler and dependency management, Tests (RSpec, Capybara), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. Debugging is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard IRB shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features syntax highlighting, a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration- and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring REPL driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# Gist integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by IPython, Smalltalk and other advanced REPLs

= Installation=

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

=Usage and Example=

===Usage===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

===Example===
Fr example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

=Pry Commands=

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

:'''Description''': It show all of the available methods that can be called by an object

:2. _

:'''Description''': Last output

:3. ? <Object>

:'''Description''': Shows more information (doc) about an object, or method

:4. cat <File>

:'''Description''': Display the content of a file

:5. _file_

:'''Description''': Represent the last file Pry touched

:6. wtf?

:'''Description''': Print the stack trace, same as _ex_.backtrace

:7. $

:'''Description''': Show source, shortcut for show-source

:8. edit <Method>

:'''Description''': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

:'''Description''': Search history

:10. _out_

:'''Description''': Array of all outputs values, also _in_

:11. cd <var>

:'''Description''': Step into an object, change the value of self

:12. cd ..

:'''Description''': Take out of a level

:13. binding.pry

:'''Description''': Breakpoint

:14. edit --ex

:'''Description''': Edit the file where the last exception was thrown

:15. .<Shell>

:'''Description''': Runs the <Shell> command

:16. whereami

:'''Description''': Print the context where the debugger is stopped

:17. ;

:'''Description''': Would mute the return output by Ruby

:18. play -l

:'''Description''': Execute the line in the current debugging context

:The best thing to do is just type help once you've installed pry.

=See also=

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

=References=
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-20T03:50:47Z

Gshah: /* Introduction */

__TOC__

= Introduction =

[[File:Pry REPL Logo.png|right|alt=Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.| - A powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a Web application framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the model view controller, like Mailers, Routes (REST, HTTP-Verbs, Constraints), Environments and Initializers, Caching (Redis, Memcached), Assets (CSS, SASS,, JavaScript, CoffeeScript, Pipelining), Bundler and dependency management, Tests (RSpec, Capybara), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. Debugging is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard IRB shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features syntax highlighting, a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration- and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring REPL driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# Gist integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by IPython, Smalltalk and other advanced REPLs

= Installation=

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

=Usage and Example=

===Usage===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

===Example===
Fr example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

=Pry Commands=

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

:'''Description''': It show all of the available methods that can be called by an object

:2. _

:'''Description''': Last output

:3. ? <Object>

:'''Description''': Shows more information (doc) about an object, or method

:4. cat <File>

:'''Description''': Display the content of a file

:5. _file_

:'''Description''': Represent the last file Pry touched

:6. wtf?

:'''Description''': Print the stack trace, same as _ex_.backtrace

:7. $

:'''Description''': Show source, shortcut for show-source

:8. edit <Method>

:'''Description''': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

:'''Description''': Search history

:10. _out_

:'''Description''': Array of all outputs values, also _in_

:11. cd <var>

:'''Description''': Step into an object, change the value of self

:12. cd ..

:'''Description''': Take out of a level

:13. binding.pry

:'''Description''': Breakpoint

:14. edit --ex

:'''Description''': Edit the file where the last exception was thrown

:15. .<Shell>

:'''Description''': Runs the <Shell> command

:16. whereami

:'''Description''': Print the context where the debugger is stopped

:17. ;

:'''Description''': Would mute the return output by Ruby

:18. play -l

:'''Description''': Execute the line in the current debugging context

:The best thing to do is just type help once you've installed pry.

=See also=

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

=References=
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-20T03:43:39Z

Gshah: /* Pry Commands */

__TOC__

= Introduction =

[[File:Pry REPL Logo.png|right|alt=Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.|''[[Pry]]'' - A powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a Web application framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the model view controller, like Mailers, Routes (REST, HTTP-Verbs, Constraints), Environments and Initializers, Caching (Redis, Memcached), Assets (CSS, SASS,, JavaScript, CoffeeScript, Pipelining), Bundler and dependency management, Tests (RSpec, Capybara), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. Debugging is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard IRB shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features syntax highlighting, a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration- and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring REPL driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# Gist integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by IPython, Smalltalk and other advanced REPLs

= Installation=

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

=Usage and Example=

===Usage===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

===Example===
Fr example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

=Pry Commands=

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

:'''Description''': It show all of the available methods that can be called by an object

:2. _

:'''Description''': Last output

:3. ? <Object>

:'''Description''': Shows more information (doc) about an object, or method

:4. cat <File>

:'''Description''': Display the content of a file

:5. _file_

:'''Description''': Represent the last file Pry touched

:6. wtf?

:'''Description''': Print the stack trace, same as _ex_.backtrace

:7. $

:'''Description''': Show source, shortcut for show-source

:8. edit <Method>

:'''Description''': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

:'''Description''': Search history

:10. _out_

:'''Description''': Array of all outputs values, also _in_

:11. cd <var>

:'''Description''': Step into an object, change the value of self

:12. cd ..

:'''Description''': Take out of a level

:13. binding.pry

:'''Description''': Breakpoint

:14. edit --ex

:'''Description''': Edit the file where the last exception was thrown

:15. .<Shell>

:'''Description''': Runs the <Shell> command

:16. whereami

:'''Description''': Print the context where the debugger is stopped

:17. ;

:'''Description''': Would mute the return output by Ruby

:18. play -l

:'''Description''': Execute the line in the current debugging context

:The best thing to do is just type help once you've installed pry.

=See also=

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

=References=
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-20T03:43:20Z

Gshah: /* Pry Commands */

__TOC__

= Introduction =

[[File:Pry REPL Logo.png|right|alt=Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.|''[[Pry]]'' - A powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a Web application framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the model view controller, like Mailers, Routes (REST, HTTP-Verbs, Constraints), Environments and Initializers, Caching (Redis, Memcached), Assets (CSS, SASS,, JavaScript, CoffeeScript, Pipelining), Bundler and dependency management, Tests (RSpec, Capybara), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. Debugging is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard IRB shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features syntax highlighting, a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration- and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring REPL driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# Gist integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by IPython, Smalltalk and other advanced REPLs

= Installation=

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

=Usage and Example=

===Usage===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

===Example===
Fr example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

=Pry Commands=

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

:'''Description''': It show all of the available methods that can be called by an object

:# _

:'''Description''': Last output

:3. ? <Object>

:'''Description''': Shows more information (doc) about an object, or method

:4. cat <File>

:'''Description''': Display the content of a file

:5. _file_

:'''Description''': Represent the last file Pry touched

:6. wtf?

:'''Description''': Print the stack trace, same as _ex_.backtrace

:7. $

:'''Description''': Show source, shortcut for show-source

:8. edit <Method>

:'''Description''': Open file in $EDITOR, change file are auto reloaded

:9. <ctrl+r>

:'''Description''': Search history

:10. _out_

:'''Description''': Array of all outputs values, also _in_

:11. cd <var>

:'''Description''': Step into an object, change the value of self

:12. cd ..

:'''Description''': Take out of a level

:13. binding.pry

:'''Description''': Breakpoint

:14. edit --ex

:'''Description''': Edit the file where the last exception was thrown

:15. .<Shell>

:'''Description''': Runs the <Shell> command

:16. whereami

:'''Description''': Print the context where the debugger is stopped

:17. ;

:'''Description''': Would mute the return output by Ruby

:18. play -l

:'''Description''': Execute the line in the current debugging context

:The best thing to do is just type help once you've installed pry.

=See also=

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

=References=
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-20T03:41:53Z

Gshah: /* Pry Commands */

__TOC__

= Introduction =

[[File:Pry REPL Logo.png|right|alt=Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.|''[[Pry]]'' - A powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a Web application framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the model view controller, like Mailers, Routes (REST, HTTP-Verbs, Constraints), Environments and Initializers, Caching (Redis, Memcached), Assets (CSS, SASS,, JavaScript, CoffeeScript, Pipelining), Bundler and dependency management, Tests (RSpec, Capybara), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. Debugging is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard IRB shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features syntax highlighting, a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration- and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring REPL driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# Gist integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by IPython, Smalltalk and other advanced REPLs

= Installation=

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

=Usage and Example=

===Usage===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

===Example===
Fr example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

=Pry Commands=

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

:1. ls <Object>

'''Description''': It show all of the available methods that can be called by an object

# _

'''Description''': Last output

3. ? <Object>

'''Description''': Shows more information (doc) about an object, or method

4. cat <File>

'''Description''': Display the content of a file

5. _file_

'''Description''': Represent the last file Pry touched

6. wtf?

'''Description''': Print the stack trace, same as _ex_.backtrace

7. $

'''Description''': Show source, shortcut for show-source

8. edit <Method>

'''Description''': Open file in $EDITOR, change file are auto reloaded

9. <ctrl+r>

'''Description''': Search history

10. _out_

'''Description''': Array of all outputs values, also _in_

11. cd <var>

'''Description''': Step into an object, change the value of self

12. cd ..

'''Description''': Take out of a level

13. binding.pry

'''Description''': Breakpoint

14. edit --ex

'''Description''': Edit the file where the last exception was thrown

15. .<Shell>

'''Description''': Runs the <Shell> command

16. whereami

'''Description''': Print the context where the debugger is stopped

17. ;

'''Description''': Would mute the return output by Ruby

18. play -l

'''Description''': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

=See also=

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

=References=
<references />

CSC/ECE 517 Fall 2014/ch1a 26 gn

2014-09-20T03:41:17Z

Gshah: /* Features */

__TOC__

= Introduction =

[[File:Pry REPL Logo.png|right|alt=Pry REPL: a powerful IRB alternative and runtime developer console for Ruby.|''[[Pry]]'' - A powerful IRB alternative and runtime developer console for Ruby.]]
[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] is a Web application framework for Ruby. It was first released to the public in July 2004. Within months, it was a widely used development environment. Many multinational corporations are using it to create Web applications. It is the standard Web-development framework for Ruby. Models are objects that represent the components of an application that perform information processing in the problem domain. Views are objects that display some aspect of the model. They are the output mechanism for the models. Controllers are objects that control how user actions are interpreted. They are the input mechanism for the views and models.

Since a Rails application goes beyond the model view controller, like Mailers, Routes (REST, HTTP-Verbs, Constraints), Environments and Initializers, Caching (Redis, Memcached), Assets (CSS, SASS,, JavaScript, CoffeeScript, Pipelining), Bundler and dependency management, Tests (RSpec, Capybara), gems, plugins and engines used in the application, one needs to know a lot of stuff to master debugging their own application<ref>http://nofail.de/2013/10/debugging-rails-applications-in-development/</ref>. Debugging is one of the things a developer has to do most and there exists debuggers for Rails that are suitable for browsers and lack the ability to allow moving around in the call-stack and inspecting objects at runtime.

[http://pryrepl.org Pry] in literal sense means to look or inquire closely, curiously, or impertinently. Pry is a powerful alternative to the standard IRB shell for Ruby. It not only for debugging but also (and mainly) for inspecting objects. It features syntax highlighting, a flexible plugin architecture, runtime invocation and source and documentation browsing. It enables the user to browse source code, inspect objects, eliminates all the iteration- and startup time when running red/green cycles and is especially useful when you don’t know exactly how something should function in the first place.

==== Pry: super-fast, painless, debugging for the (ruby) masses. ====
Pry aims to be more than an IRB replacement; it is an attempt to bring REPL driven programming to the Ruby language. Pry is also fairly flexible and allows significant user customization making it a good choice for implementing custom shells. The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Because the shell opens as though the exception were just about to be raised, you don't even need to re-run your program from the beginning in order to start debugging. It's optimized for the "exceptions-happen" workflow that you need when developing code.

==== Features====

Pry is written from scratch to provide a number of advanced features, some of these include<ref>http://pryrepl.org</ref><ref>http://andywenk.tumblr.com/post/23821244145/rails-debugging-with-pry</ref>:

# Source code browsing (including core C source with the pry-doc gem)
# Navigation around state (cd, ls and friends)
# Rubinius core source browsing
# Documentation browsing
# Live help system
# Open methods in editors (edit-method Class#method)
# Syntax highlighting
# Command shell integration (start editors, run git, and rake from within Pry)
# Gist integration
# Runtime invocation (use Pry as a developer console or debugger)
# Exotic object support (BasicObject instances, IClasses, ...)
# A powerful and flexible command system
# Ability to view and replay history
# Many convenience commands inspired by IPython, Smalltalk and other advanced REPLs

= Installation=

The steps you have to do are simple<ref>http://www.sitepoint.com/pry-friends-rails</ref>:

<pre>
$ gem install pry
$ pry
</pre>

You could install pry on Rails by adding the pry-rails gem to your gem file:

<pre>
group :development do
gem 'pry'
...
end
</pre>

Once you have got that settled, change back into the sample_app directory and install all the necessary dependencies:

<pre>
bundle install
</pre>

Setting up the database:

<pre>
rake db:schema:load
</pre>

Note that some of you might need to prefix the above command with bundle exec.

One final thing before we proceed to the actual stuff: Create .pryrc in your home directory and fill it in with the editor of your choice:

<pre>
% touch ~/.pryrc
Pry.config.editor = 'vim'
</pre>

To launch pry through the terminal you simply write:

<pre>
rails c
</pre>

and you’re greeted with a pry console:

<pre>
% rails c
Loading development environment (Rails 3.2.16)
Frame number: 0/3
[1] sample_app »
</pre>

=Usage and Example=

===Usage===
After you install Pry using the above mentioned install command, you run your program using '''rescue foo.rb''' instead of '''ruby foo.rb'''. If not, just wrap chunks of your program in Pry::rescue{ }. Any exceptions that are unhandled within that block will be rescued by pry on your behalf.

Whenever pry opens because of an exception you have two choices:
# Hit '''ctrl-d''' to let the exception bubble on its way
# Do some debugging.

If you choose the second option, then you can use the full power of pry to fix the problem; and then try-again to verify the fix worked.

===Example===
Fr example, lets assume the following piece of code<ref>http://cirw.in/blog/pry-to-the-rescue</ref>:
<pre>
def find_capitalized(a)
a.select do |name|
name.chars.first == name.chars.first.upcase
end
end
</pre>

Now if you run '''rescue foo.rb''', you would get a output which would look like this:
<pre>
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
3: a.select do |name|
=> 4: name.chars.first == name.chars.first.upcase
5: end
6: end

NoMethodError: undefined method `chars' for :direction:Symbol
from rescue.rb:4:in `block in find_capitalized'
[1] pry(main)>
</pre>

Well, clearly it's gone wrong. Let's move up the stack and see if we can find which code is calling this method with symbols:

<pre>
[1] pry(main)> up
From: rescue.rb @ line 8 Object#extract_people:

8: def extract_people(opts)
=> 9: name_keys = find_capitalized(opts.keys)
10:
11: name_keys.each_with_object({}) do |name, o|
12: o[name] = opts.delete name
13: end
14: end

[2] pry(main)> opts
=> {"Arthur"=>"Dent", :direction=>:left}
</pre>

Let's see if there's a better way of implementing find_capitalized:

<pre>
[3] pry(main)> down
[4] pry(main)> name.first
NoMethodError: undefined method `first' for :direction
from (pry):9:in `block in find_capitalized'
[5] pry(main)> name.capitalize
=> :Direction
</pre>

Let's edit-method to fix the code, and try-again to verify the fix worked:
<pre>
[6] pry(main)> edit-method
[7] pry(main)> whereami
From: rescue.rb @ line 2 Object#find_capitalized:

2: def find_capitalized(a)
=> 3: a.select do |name|
4: name.capitalize == name
5: end
6: end

[8] pry(main)> try-again
Arthur Dent moves left
</pre>

=Pry Commands=

There are a myriad of pry commands that are useful while debugging. Follwing is the list of some important list of commands that can be used while debugging using Pry<ref>http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html</ref><ref>http://cirw.in/blog/pry-to-the-rescue</ref><ref>http://www.sitepoint.com/pry-friends-rails</ref><ref>https://github.com/ConradIrwin/pry-rescue</ref>.

# ls <Object>

'''Description''': It show all of the available methods that can be called by an object

# _

'''Description''': Last output

3. ? <Object>

'''Description''': Shows more information (doc) about an object, or method

4. cat <File>

'''Description''': Display the content of a file

5. _file_

'''Description''': Represent the last file Pry touched

6. wtf?

'''Description''': Print the stack trace, same as _ex_.backtrace

7. $

'''Description''': Show source, shortcut for show-source

8. edit <Method>

'''Description''': Open file in $EDITOR, change file are auto reloaded

9. <ctrl+r>

'''Description''': Search history

10. _out_

'''Description''': Array of all outputs values, also _in_

11. cd <var>

'''Description''': Step into an object, change the value of self

12. cd ..

'''Description''': Take out of a level

13. binding.pry

'''Description''': Breakpoint

14. edit --ex

'''Description''': Edit the file where the last exception was thrown

15. .<Shell>

'''Description''': Runs the <Shell> command

16. whereami

'''Description''': Print the context where the debugger is stopped

17. ;

'''Description''': Would mute the return output by Ruby

18. play -l

'''Description''': Execute the line in the current debugging context

The best thing to do is just type help once you've installed pry.

=See also=

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

* [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Debug code]

* [http://object.io/site/2011/getting-to-know-ruby-debugger/ Ruby debugger]

* [http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Interactive Ruby Shell]

* [http://guides.rubyonrails.org/debugging_rails_applications.html Debugging Rails application tutorials]

=References=
<references />