Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T04:08:48Z

Samirajk: /* RUST Programming Language */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>http://en.wikipedia.org/wiki/Servo_(layout_engine)</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://en.wikipedia.org/wiki/Rust_(programming_language)</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Implementation Steps =
==='''Step 1'''===
The first step includes building Servo.

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.

= Steps to execute our program =
*The first step is to install Rust in your machine. Steps can be found at <ref>https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref>
*The next step is to build Servo. Steps can be found at <ref>https://github.com/servo/servo</ref>
[[File:Build servo.png]]
 
[[File:Building servo fin.png]]
*Our implementation files are “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs errorevent.rs]” and “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl errorevent.webidl]”.
*Binding will be automatically generated. The binding file is “ErrorEventBinding.rs”
*Build servo again
<pre>
./mach build
</pre>
*We can now run the servo using the following command
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T04:07:47Z

Samirajk: /* Introduction */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>http://en.wikipedia.org/wiki/Servo_(layout_engine)</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Implementation Steps =
==='''Step 1'''===
The first step includes building Servo.

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.

= Steps to execute our program =
*The first step is to install Rust in your machine. Steps can be found at <ref>https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref>
*The next step is to build Servo. Steps can be found at <ref>https://github.com/servo/servo</ref>
[[File:Build servo.png]]
 
[[File:Building servo fin.png]]
*Our implementation files are “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs errorevent.rs]” and “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl errorevent.webidl]”.
*Binding will be automatically generated. The binding file is “ErrorEventBinding.rs”
*Build servo again
<pre>
./mach build
</pre>
*We can now run the servo using the following command
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T04:05:38Z

Samirajk: /* Project Description */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Implementation Steps =
==='''Step 1'''===
The first step includes building Servo.

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.

= Steps to execute our program =
*The first step is to install Rust in your machine. Steps can be found at <ref>https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref>
*The next step is to build Servo. Steps can be found at <ref>https://github.com/servo/servo</ref>
[[File:Build servo.png]]
 
[[File:Building servo fin.png]]
*Our implementation files are “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs errorevent.rs]” and “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl errorevent.webidl]”.
*Binding will be automatically generated. The binding file is “ErrorEventBinding.rs”
*Build servo again
<pre>
./mach build
</pre>
*We can now run the servo using the following command
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T04:03:08Z

Samirajk: /* Implementation Steps */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
==='''Step 1'''===
The first step includes building Servo.

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.

= Steps to execute our program =
*The first step is to install Rust in your machine. Steps can be found at <ref>https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref>
*The next step is to build Servo. Steps can be found at <ref>https://github.com/servo/servo</ref>
[[File:Build servo.png]]
 
[[File:Building servo fin.png]]
*Our implementation files are “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs errorevent.rs]” and “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl errorevent.webidl]”.
*Binding will be automatically generated. The binding file is “ErrorEventBinding.rs”
*Build servo again
<pre>
./mach build
</pre>
*We can now run the servo using the following command
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T04:00:47Z

Samirajk: /* Step 2 */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
==='''Step 1:'''===
The first step includes building Servo.

==='''Step 2:'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
*Check if it works using this command:

= Steps to execute our program =
*The first step is to install Rust in your machine. Steps can be found at <ref>https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref>
*The next step is to build Servo. Steps can be found at <ref>https://github.com/servo/servo</ref>
[[File:Build servo.png]]
 
[[File:Building servo fin.png]]
*Our implementation files are “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs errorevent.rs]” and “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl errorevent.webidl]”.
*Binding will be automatically generated. The binding file is “ErrorEventBinding.rs”
*Build servo again
<pre>
./mach build
</pre>
*We can now run the servo using the following command
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T04:00:31Z

Samirajk: /* Step 1 */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
==='''Step 1:'''===
The first step includes building Servo.

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
*Check if it works using this command:

= Steps to execute our program =
*The first step is to install Rust in your machine. Steps can be found at <ref>https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref>
*The next step is to build Servo. Steps can be found at <ref>https://github.com/servo/servo</ref>
[[File:Build servo.png]]
 
[[File:Building servo fin.png]]
*Our implementation files are “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs errorevent.rs]” and “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl errorevent.webidl]”.
*Binding will be automatically generated. The binding file is “ErrorEventBinding.rs”
*Build servo again
<pre>
./mach build
</pre>
*We can now run the servo using the following command
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:58:07Z

Samirajk: /* Steps to execute our program */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

= Steps to execute our program =
*The first step is to install Rust in your machine. Steps can be found at <ref>https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref>
*The next step is to build Servo. Steps can be found at <ref>https://github.com/servo/servo</ref>
[[File:Build servo.png]]
 
[[File:Building servo fin.png]]
*Our implementation files are “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs errorevent.rs]” and “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl errorevent.webidl]”.
*Binding will be automatically generated. The binding file is “ErrorEventBinding.rs”
*Build servo again
<pre>
./mach build
</pre>
*We can now run the servo using the following command
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:57:28Z

Samirajk: /* Project Description */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

= Steps to execute our program =
*The first step is to install Rust in your machine. Steps can be found at <ref>https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref>
*The next step is to build Servo. Steps can be found at <ref>https://github.com/servo/servo</ref>
[[File:Build servo.png]]
[[File:Building servo fin.png]]
*Our implementation files are “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs errorevent.rs]” and “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl errorevent.webidl]”.
*Binding will be automatically generated. The binding file is “ErrorEventBinding.rs”
*Build servo again
<pre>
./mach build
</pre>
*We can now run the servo using the following command
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:56:50Z

Samirajk: /* Steps to execute our program */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

= Steps to execute our program =
*The first step is to install Rust in your machine. Steps can be found at <ref>https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref>
*The next step is to build Servo. Steps can be found at <ref>https://github.com/servo/servo</ref>
[[File:Build servo.png]]
[[File:Building servo fin.png]]
*Our implementation files are “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs errorevent.rs]” and “[https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl errorevent.webidl]”.
*Binding will be automatically generated. The binding file is “ErrorEventBinding.rs”
*Build servo again
<pre>
./mach build
</pre>
*We can now run the servo using the following command
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:42:30Z

Samirajk: /* Step 2 */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Steps to execute our program =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/blob/master/components/script/dom/webidls/ErrorEvent.webidl 'ErrorEvent.webidl'] and add it to ''components/script/dom/webidls''.
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the ''components/script/dom location''.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
 
 
[[File:Building servo fin.png]]
 
 
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:38:12Z

Samirajk: /* Project Description */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generated ErrorEventBinding.rs file.
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file 'errorevent.webidl' along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

= Steps to execute our program =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/tree/master/components/script/dom/webidls 'errorevent.webidl'] and add it to components/script/dom/webidls
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
 
 
[[File:Building servo fin.png]]
 
 
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:37:16Z

Samirajk: /* Servo */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file 'errorevent.webidl' along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

= Steps to execute our program =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/tree/master/components/script/dom/webidls 'errorevent.webidl'] and add it to components/script/dom/webidls
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
 
 
[[File:Building servo fin.png]]
 
 
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:36:55Z

Samirajk: /* RUST Programming Language */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

= Servo =

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file 'errorevent.webidl' along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

= Steps to execute our program =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file [https://github.com/RonakNisher/servo/tree/master/components/script/dom/webidls 'errorevent.webidl'] and add it to components/script/dom/webidls
*Create the [https://github.com/RonakNisher/servo/blob/master/components/script/dom/errorevent.rs 'errorevent.rs'] file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
 
 
[[File:Building servo fin.png]]
 
 
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:35:58Z

Samirajk: /* Servo */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref><ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

= RUST Programming Language =

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

= Servo =

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time)<ref>http://en.wikipedia.org/wiki/Just-in-time_compilation</ref> compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors<ref>http://en.wikipedia.org/wiki/ARM_architecture</ref>.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file 'errorevent.webidl' along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

= Steps to execute our program =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file 'errorevent.webidl' and add it to components/script/dom/webidls
*Create the 'errorevent.rs' file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
 
 
[[File:Building servo fin.png]]
 
 
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:32:40Z

Samirajk: /* RUST Programming Language */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

= RUST Programming Language =

[http://en.wikipedia.org/wiki/Servo_(layout_engine) Servo] is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

= Servo =

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

= Steps to execute our program =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file 'errorevent.webidl' and add it to components/script/dom/webidls
*Create the 'errorevent.rs' file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
 
 
[[File:Building servo fin.png]]
 
 
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:29:52Z

Samirajk: /* Introduction */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named ''rust-mozjs'' library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

= RUST Programming Language =

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

= Servo =

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

= Steps to execute our program =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file 'errorevent.webidl' and add it to components/script/dom/webidls
*Create the 'errorevent.rs' file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
 
 
[[File:Building servo fin.png]]
 
 
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:28:24Z

Samirajk: /* Introduction */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. SpiderMonkey has been written in C/C++. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

= RUST Programming Language =

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

= Servo =

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

= Steps to execute our program =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file 'errorevent.webidl' and add it to components/script/dom/webidls
*Create the 'errorevent.rs' file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
 
 
[[File:Building servo fin.png]]
 
 
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:26:53Z

Samirajk: /* Introduction */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the [http://en.wikipedia.org/wiki/JavaScript JavaScript] search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

= RUST Programming Language =

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

= Servo =

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

= Steps to execute our program =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file 'errorevent.webidl' and add it to components/script/dom/webidls
*Create the 'errorevent.rs' file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
 
 
[[File:Building servo fin.png]]
 
 
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:24:50Z

Samirajk: /* Introduction */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. With the main goal of creating an architecture that is parallel at many levels, common sources of bugs and security vulnerabilities associated with incorrect memory management are thereby eliminated.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

= RUST Programming Language =

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

= Servo =

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

= Steps to execute our program =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file 'errorevent.webidl' and add it to components/script/dom/webidls
*Create the 'errorevent.rs' file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
 
 
[[File:Building servo fin.png]]
 
 
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:22:00Z

Samirajk: /* Implementing proper JS error reporting */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

= Introduction =
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

= RUST Programming Language =

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

= Servo =

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

= Project Description =
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

= Implementation Steps =
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

= Steps to execute our program =
=='''Step 1'''==
The first step includes building Servo.
<pre>
./mach build
</pre>

=='''Step 2'''==
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file 'errorevent.webidl' and add it to components/script/dom/webidls
*Create the 'errorevent.rs' file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
 
 
[[File:Building servo fin.png]]
 
 
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

= Design Principles =

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

= Future work =

= References =
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:17:49Z

Samirajk: /* Step 2 */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

== Introduction ==
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file 'errorevent.webidl' and add it to components/script/dom/webidls
*Create the 'errorevent.rs' file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
 
 
[[File:Building servo fin.png]]
 
 
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png]]

== Design Principles ==

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:17:11Z

Samirajk: /* Step 2 */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

== Introduction ==
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.
[[File:Servo arch.png|frame|center|alt = Servo Architecture|Servo Achitecture]]

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a 'errorevent.rs' file, which is written in RUST programming language.
*The file on compilation generates 'erroreventBinding.rs' file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file 'errorevent.webidl' and add it to components/script/dom/webidls
*Create the 'errorevent.rs' file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
[[File:Building servo.png]]
 
 
[[File:Building servo fin.png]]
 
 
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:After running program.png|frame|left|alt = Running servo|After running servo]]

== Design Principles ==

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:08:06Z

Samirajk: /* Introduction */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

== Introduction ==
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance [http://en.wikipedia.org/wiki/Graphics_processing_unit GPUs]. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a errorevent.rs file, which is written in RUST programming language.
*The file on compilation generates erroreventBinding.rs file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
[[File:Building servo.png|frame|center|alt = Building Servo|Step to build servo]]

== Design Principles ==

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:06:12Z

Samirajk: /* Introduction */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

== Introduction ==
[http://en.wikipedia.org/wiki/Mozilla Mozilla] is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a errorevent.rs file, which is written in RUST programming language.
*The file on compilation generates erroreventBinding.rs file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

== Design Principles ==

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:03:55Z

Samirajk: /* Implementing proper JS error reporting */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Rust_(programming_language) RUST] programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a errorevent.rs file, which is written in RUST programming language.
*The file on compilation generates erroreventBinding.rs file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

== Design Principles ==

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T03:03:24Z

Samirajk: /* Implementing proper JS error reporting */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using [http://en.wikipedia.org/wiki/Debug_code#Print_debugging RUST] programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL<ref>https://github.com/servo/servo/wiki/Adding-a-new-WebIDL-binding</ref> file errorevent.webidl along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust
</ref> programming language.
* The file on compilation generates ErrorEventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a errorevent.rs file, which is written in RUST programming language.
*The file on compilation generates erroreventBinding.rs file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

== Design Principles ==

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:59:48Z

Samirajk: /* Step 2 */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST programming language.
* The file on compilation generates erroreventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a errorevent.rs file, which is written in RUST programming language.
*The file on compilation generates erroreventBinding.rs file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

== Design Principles ==

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:59:27Z

Samirajk: /* Design Principles */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo<ref>http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
</ref> is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST programming language.
* The file on compilation generates erroreventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a errorevent.rs file, which is written in RUST programming language.
*The file on compilation generates erroreventBinding.rs file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
:*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
:*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
:*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
:*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
:*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

== Design Principles ==

*'''Simple''': We have tried to not complicate the code but keep it simple.
*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:58:56Z

Samirajk: /* Implementation Steps */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST programming language.
* The file on compilation generates erroreventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
*We were required to write a errorevent.rs file, which is written in RUST programming language.
*The file on compilation generates erroreventBinding.rs file
*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
:*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
:*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
:*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
:*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
:*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

== Design Principles ==

:*'''Simple''': We have tried to not complicate the code but keep it simple.
:*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
:*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
:*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:58:38Z

Samirajk: /* Project Description */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo is written in RUST<ref>http://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust</ref> programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
* We were required to write a errorevent.rs file, which is written in RUST programming language.
* The file on compilation generates erroreventBinding.rs file
* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
:*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
:*We were required to write a errorevent.rs file, which is written in RUST programming language.
:*The file on compilation generates erroreventBinding.rs file
:*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
:*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
:*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
:*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
:*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
:*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

== Design Principles ==

:*'''Simple''': We have tried to not complicate the code but keep it simple.
:*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
:*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
:*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:57:32Z

Samirajk: /* References */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo<ref>https://github.com/servo/servo</ref>, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey<ref>https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey</ref> has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo is written in RUST programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
:* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
:* We were required to write a errorevent.rs file, which is written in RUST programming language.
:* The file on compilation generates erroreventBinding.rs file
:* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==
:*The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
:*We were required to write a errorevent.rs file, which is written in RUST programming language.
:*The file on compilation generates erroreventBinding.rs file
:*The project was then rebuilt and recompiled on the Servo engine.

== Steps to execute our program ==
==='''Step 1'''===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2'''===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
:*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
:*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
:*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
:*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
:*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>

== Design Principles ==

:*'''Simple''': We have tried to not complicate the code but keep it simple.
:*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
:*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
:*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==
<references />

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:53:26Z

Samirajk: /* Project Description */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo is written in RUST programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==
:* The project requirements needed us to build a Servo, add a new file ErrorEvent WebIDL file along with its RUST implementation, and create the errorevent interface.
:* We were required to write a errorevent.rs file, which is written in RUST programming language.
:* The file on compilation generates erroreventBinding.rs file
:* The project was then rebuilt and recompiled on the Servo engine.

== Implementation Steps ==

== Steps to execute our program ==
==='''Step 1''':===
The first step includes building Servo.
<pre>
./mach build
</pre>

==='''Step 2''':===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
:*Create a new file ‘errorevent.webidl’ and add it to components/script/dom/webidls
:*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
:*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
:*Build servo and fix any compile errors in the implementation.
<pre>
./mach build
</pre>
:*Check if it works using this command:
<pre>
./mach run tests/html/about-mozilla.html
</pre>
== Design Principles ==

:*'''Simple''': We have tried to not complicate the code but keep it simple.
:*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
:*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
:*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:49:46Z

Samirajk: /* Servo */

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==
Mozilla is currently working on a research project called Servo, which is a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. The goal is to create an architecture that is parallel at many levels thereby eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management.

For the new browser Mozilla servo, SpiderMonkey has been used as the JavaScript search engine. SpiderMonkey basically exposes a user-specifiable callback that executes JS and throws an exception that is not caught. But, SpiderMonkey has been written in C/C++. It exposes a user-specifiable callback executing JS that throws an exception that is not caught. Initially, the library (which wraps the C-based mozjs aka SpiderMonkey) named rust-mozjs library sets this callback to a simple function that pushed the error logs on to the terminal. Thus, as a part of our OSS project, based on the requirements, we have presented a way to replace this in Servo with an ErrorEvent interface which has methods that implements the error reporting specification for web browsers.

== RUST Programming Language ==

Servo is written in RUST programming language which is developed by Mozilla research. It is memory safe thereby ensuring a high degree of assurance in the browser’s trusted computing base. RUST also guarantees concurrency thus avoiding the problem of ‘data races’ and ensures safety and speed. Rust’s lightweight task mechanism also allows fine-grained isolation between browser components.

== Servo ==

Mozilla has planned to deliver its new browser Servo which facilitates great features like parallel processing in the browser in order to utilize many cores present in the modern mobile devices such as smartphones and tablets in order to carry out tasks concurrently. Even the giant and famous browsers like Chrome, Internet Explorer, Firefox, Safari, have tried to implement parallel processing via different ways such as aggregating the JIT (Just in Time) compilation technique to their JS engines. But, performance and security gains need re-modelling the browser stacks of these browsers. Servo, that is being designed to be compatible with the Android OS devices, will work with the Arm-based processors.

== Project Description ==

== Implementation Steps ==

== Steps to execute our program ==
==='''Step 1''':===
The first step includes building Servo.
==='''Step 2''':===
Once the Servo is built, the next step is to create an errorevent interface by adding a new WebIDL binding. The following are the steps to create a new WebIDL file:
:*Create a new file ‘errorevent.webild’ and add it to components/script/dom/webidls
:*Create the errorevent.rs file containing a Reflector at minimum, as well as implementation of the Reflectable trait and add it at the components/script/dom location.
:*Add the implementation's module to the script crate lib.rs to ensure it is compiled.
:*Build servo and fix any compile errors in the implementation.

== Design Principles ==

:*'''Simple''': We have tried to not complicate the code but keep it simple.
:*'''Readable''': By adding necessary and required comments, we have made our code readable to other programmers.
:*'''Reusable''': We have tried and made our code capable of being used in a completely different setting.
:*'''Efficient''': Our code gives the results in reasonable amount of time.

== Future work ==

== References ==

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:47:53Z

Samirajk: /* RUST Programming Language */

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:45:15Z

Samirajk: /* Introduction */

CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:42:17Z

Samirajk: Created page with "= '''Implementing proper JS error reporting''' = This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language. __TO..."

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==

== RUST Programming Language ==

== Servo ==

== Project Description ==

== Implementation Steps ==

== Steps to execute our program ==

== Design Principles ==

== Future work ==

== References ==

Talk:CSC/ECE 517 Fall 2014/oss M1454 rss

2014-10-29T02:41:04Z

= '''Implementing proper JS error reporting''' =

This wiki page contains the implementation of JS error reporting for the Mozilla project using RUST programming language.

__TOC__

== Introduction ==

== RUST Programming Language ==

== Servo ==

== Project Description ==

== Implementation Steps ==

== Steps to execute our program ==

== Design Principles ==

== Future work ==

== References ==

CSC/ECE 517 Fall 2014/ch1a 26 sn

2014-09-26T03:10:57Z

Samirajk: /* Comparison with other debugging tools */

= '''Debugging in Rails using Pry''' =

Debugging is a process of finding and reducing the bugs or defects in a computer program thereby making it behave as expected. Few of the debugging techniques are [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Print debugging] (also known as printf debugging), Log debugging and Interactive debugging<ref>http://rubylearning.com/satishtalim/ruby_logging.html</ref><ref>http://object.io/site/2011/getting-to-know-ruby-debugger/</ref>.
[http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] provides a range of options to make debugging<ref>http://en.wikipedia.org/wiki/Debugging</ref> easier which include debug helpers, loggers, graphical debuggers, Pry, and so on<ref>http://guides.rubyonrails.org/debugging_rails_applications.html</ref>. In the following sections, debugging in rails using PRY is being explained.

__TOC__

= Introduction to Pry debugger =

:Pry is an [http://en.wikipedia.org/wiki/Shell_(computing) interactive shell] for the Ruby programming language. Pry could be started at any point within a running program. Due to this, programmers can inspect the program, correct the source code, or change its current state without having to restart the process. Pry is thus notable for its ability to start a [http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop REPL] within a running program.

:Pry has many features that make it extremely efficient to use. One of the example here could be Pry's ''hist --grep'' that makes it easy to search through your Pry history. Also, Pry uses the filesystem metaphor for exposing most of its introspective capabilities such as the ''ls'' command to list the methods and variables and the ''cd'' command to start interacting with a particular object.

:To start a debugging session, the ''require 'pry' '' and ''binding.pry'' lines need to be included in the program that needs to be debugged. The line ''binding.pry'' could be inserted at any point in your program. Whenever the Ruby interpreter executes this line, it opens a Pry REPL session. The code after the ''binding.pry'' statement is not executed unless instructed by the programmer. Changes could be made to fix the code and then return to running program from same point.

== Installation ==

:To use Pry for debugging a Rails application, you first need to download and install Pry-debugger. If you are using Ruby version 2.0 or higher, then download pry-debugger from [https://github.com/deivid-rodriguez/pry-byebug here]. If you are using Ruby version 1.9 or lower, then download pry-debugger from [https://rubygems.org/gems/pry-debugger here].

:To install the debugger use the following command:<ref>http://pryrepl.org/</ref>
<pre>
gem install pry-debugger.gem
</pre>
:Include the following line of code on the gem file:
<pre>
gem 'pry-rails', :group => :development
</pre>
:Once that is done, the necessary dependencies could be installed using the following command:
<pre>
$bundle install
</pre>

= Execution Commands =
:To use the execution command, invoke pry normally. There is no need to start your script or application differently. For the sake of clarity in explanation, we would refer to the program below:
<pre>
require 'pry'
def method1 (seller)
puts 'Inside method 1'
method2(seller)
end

def method2(seller)
binding.pry # Execution will stop here.
new_products = method3(seller)
puts 'After calling method3'
end

def method3(seller)
puts 'Inside method 3'
puts 'Continuing in method 3'
end

method1('xyz')

</pre>

=== The Step command: ===
:The ''step'' command continues execution by moving into the method on the next line. To put it in another way, the command takes us deeper into the method. Following our example, the ''step'' command would take us into ''method3'' at which point we would be asked what to do next. The following screenshot demonstrates our example:

[[File:Step.jpg]]

=== The Next command: ===
:The ''next'' command runs the current line and moves to the next line in the current context. If the next line in the code is a method call, then unlike the ''step'' method the execution does not go deeper into the method. Following our example, if we execute the above code, the execution stop at the ''binding.pry'' line and the debugger asks us for the further action. On using the ''next'' command, the execution moves to the next line that is '' new_products = method3(seller)'' without going deeper into the method. The debugger now waits for another instruction from the programmer and if the command is ''next'' again, the debugger simply goes to the next line of code after executing the method. Thus, all the code within the ''method3'' method (which would otherwise be many steps), has been concluded with a single use of the ''next'' command. The example could be seen in the following screenshot:

[[File:Next.jpg]]

=== The Finish command: ===
:Now once we have stepped into a method using the ''step'' command, the debugger would ask us what needs to be done next. Now if we want to jump to the end of the method without the debugger asking us our choice of navigation command at the end of each line, we could use the ''finish'' command. The ''finish'' command would execute the code in the method and return back to the point from where the method was called. In our example, while the debugger is in ''method3'', the ''finish'' command would complete the code execution in ''method3'' and return back to ''method2''.

=== The Continue command: ===
:With this command we can abandon the pry session and continue the normal execution of the program. If the interpreter encounters another ''binding.pry'', a pry session is again opened. This can be incredibly annoying, since our program will stop and we’ll have to navigate the debugger every single time, so we’ll probably want to type exit-program to cancel the effect of any following ''binding.pry'' statements, thereby exiting our rails application.

=== Breakpoints: ===
:You could set or change the breakpoints in a program directly using Pry. The ''break'' command is used for this purpose. You could set breakpoints in the current file, or in any other file, or a method. Conditional breakpoints could also be changed or set using optional expressions.

:Command to display the list of breakpoints and conditional breakpoints:
<pre>
break --condition 4 x > 2 Change condition on breakpoint #4 to 'x > 2'.
break --condition 6 Remove the condition on breakpoint #6.
break List all breakpoints. (Same as `breakpoints`)
break --show 2 Show details about breakpoint #2.
</pre>
:Setting breakpoints:
<pre>
break 5 Break at line 5 in the current file.
break <class_name>#run Break at the start of `<class_name>#run`.
break app/models/test.rb:4 Break at line 4 in test.rb.
</pre>
:Deleting breakpoints:
<pre>
break --delete 5 Delete breakpoint #5.
break --disable-all Disable all breakpoints.
</pre>

=== The Edit command: ===
:You could edit the code in a file by just switching to the editor rather than having to end the Pry session. This could be done using the ''edit'' command<ref>http://kgrz.io/pry/2014/02/07/Prys-edit-command.html</ref>. On using the ''edit'' command, a new editor window pops up thereby enabling the programmer to edit the code. However, you need to specify the type of editor in the ''.pryrc'' file. For example, in order to edit the code using a Notepad editor, you need to specify the following in the ''.pryrc'' file:
<pre>
Pry.config.editor = 'Notepad'
</pre>
[[File:SnOutput1.jpg]]

=== View the documentation or source for a method: ===
:You sometimes would want to know how a particular method works or what kind of arguments it takes. The ''show-doc'' method could help you determine that. Also, you would want to know the source of the method. This could be done using the ''show-method'' command.
<pre>
pry(main)> def foo
pry(main)* puts "Welcome to the foo!!"
pry(main)* end
=> nil
pry(main)> show-method foo

From: (pry) @ line 3:
Number of lines: 3
Owner: Object
Visibility: private

def foo
puts "Welcome to the foo!!"
end
</pre>

=== List of other commonly used commands: ===
:The other list of commands could be found by typing ''help''<ref>https://github.com/pry/pry/wiki/Command-system#Help_command</ref>. The following shows other list of commands:

[[File:Help1.jpg]]

:Interested people can learn more about using Pry as a debugger by watching the video [http://www.youtube.com/watch?v=o90CCPjcIKE tutorial].

= Remote Debugging<ref>http://wiki.freepascal.org/Remote_Debugging</ref> =
:So far, Pry has been a good tool to digging into the code and checking how the code is actually working and what is exactly going on inside the code. We used ''binding.pry'' inside the program where the execution stops and the user is asked to give further instructions. However, there are situations where the execution of the program would not stop and the would not allow you to inspect the code especially in situations when [https://github.com/yegrb/yeg-wiki/wiki/Managing-application-processes-with-the-Foreman-gem Foreman] is used to manage processes. In such situation, ''pry-remote'' could be of help.

:When a process that is being run by Foreman comes across ''binding.pry'', it would halt but a Pry session would not be opened. You would be forced to kill the process as the application actually freezes. Thus, in such cases ''pry-remote'' would be a great solution and in order to work around with this, you need to first install the gem:
<pre>
gem install pry-remote
</pre>
:Then run bundler:
<pre>
bundle install
</pre>
:Once you have installed ''pry-remote'', a breakpoint can be added using ''binding.remote_pry'' anywhere in the program from where the code needs to be debugged.
<pre>
def index
binding.remote_pry
...
end
end

</pre>
:''Pry-remote'' would block your program when it hits the ''binding.remote_pry'' and open a Drb endpoint that a client can connect to<ref>http://www.ruby-doc.org/stdlib-1.9.3/libdoc/drb/rdoc/DRb.html</ref>. Running pry-remote in a shell will then connect to the session. You would then be able to interact with Pry as you would normally do. You could unblock the program by using ''exit''.

= Comparison with other debugging tools =
Pry is a replacement for Ruby's default REPL,irb. It has many more additional features as compared to irb. Some of the features that provide Pry an edge over the other debugging tools are as follows:
:*Pry enables code or syntax highlighting, auto identation and a runtime debugging console.
:*It has the ability to load any portion of the file in your text editor directly into the REPL session.

Other Debuggers available in the market are:
:*[http://www.jetbrains.com/ruby/quickstart/ JetBrains RubyMine] Commercial but very easy to use windows based debugger. It supports Ruby versions from 1.8.6 to 2.1.
:*[http://komodoide.com/features/ Komodo] Commercial IDE used for Ruby and other languages like Perl and java. It has graphical debugger and supports multi-process debugging.
:*[http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-chrome-devtools.html Chrome Dev-tools] The elements tab is used to debug and get rapid feedback about experimental design changes in HTML or CSS.
:*[http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-memcached.html Memcached] In production environment this tool can be used in addition with Heroku to access detailed stats about Memcached usage to find if you have high hit rate or low eviction rate.
:*[http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-operating-system-tools.html Operating System Tools] Mostly a mixture of commands used to debug only specific errors for example, Curl to debug URL's or G Debugger to debug infinite loops.

= Reference =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 sn

2014-09-25T22:52:41Z

Samirajk: /* List of other commonly used commands: */

= '''Debugging in Rails using Pry''' =

Debugging is a process of finding and reducing the bugs or defects in a computer program thereby making it behave as expected. Few of the debugging techniques are [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Print debugging] (also known as printf debugging), Log debugging and Interactive debugging<ref>http://rubylearning.com/satishtalim/ruby_logging.html</ref><ref>http://object.io/site/2011/getting-to-know-ruby-debugger/</ref>.
[http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] provides a range of options to make debugging<ref>http://en.wikipedia.org/wiki/Debugging</ref> easier which include debug helpers, loggers, graphical debuggers, Pry, and so on<ref>http://guides.rubyonrails.org/debugging_rails_applications.html</ref>. In the following sections, debugging in rails using PRY is being explained.

__TOC__

= Introduction to Pry debugger =

:Pry is an [http://en.wikipedia.org/wiki/Shell_(computing) interactive shell] for the Ruby programming language. Pry could be started at any point within a running program. Due to this, programmers can inspect the program, correct the source code, or change its current state without having to restart the process. Pry is thus notable for its ability to start a [http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop REPL] within a running program.

:Pry has many features that make it extremely efficient to use. One of the example here could be Pry's ''hist --grep'' that makes it easy to search through your Pry history. Also, Pry uses the filesystem metaphor for exposing most of its introspective capabilities such as the ''ls'' command to list the methods and variables and the ''cd'' command to start interacting with a particular object.

:To start a debugging session, the ''require 'pry' '' and ''binding.pry'' lines need to be included in the program that needs to be debugged. The line ''binding.pry'' could be inserted at any point in your program. Whenever the Ruby interpreter executes this line, it opens a Pry REPL session. The code after the ''binding.pry'' statement is not executed unless instructed by the programmer. Changes could be made to fix the code and then return to running program from same point.

== Installation ==

:To use Pry for debugging a Rails application, you first need to download and install Pry-debugger. If you are using Ruby version 2.0 or higher, then download pry-debugger from [https://github.com/deivid-rodriguez/pry-byebug here]. If you are using Ruby version 1.9 or lower, then download pry-debugger from [https://rubygems.org/gems/pry-debugger here].

:To install the debugger use the following command:<ref>http://pryrepl.org/</ref>
<pre>
gem install pry-debugger.gem
</pre>
:Include the following line of code on the gem file:
<pre>
gem 'pry-rails', :group => :development
</pre>
:Once that is done, the necessary dependencies could be installed using the following command:
<pre>
$bundle install
</pre>

= Execution Commands =
:To use the execution command, invoke pry normally. There is no need to start your script or application differently. For the sake of clarity in explanation, we would refer to the program below:
<pre>
require 'pry'
def method1 (seller)
puts 'Inside method 1'
method2(seller)
end

def method2(seller)
binding.pry # Execution will stop here.
new_products = method3(seller)
puts 'After calling method3'
end

def method3(seller)
puts 'Inside method 3'
puts 'Continuing in method 3'
end

method1('xyz')

</pre>

=== The Step command: ===
:The ''step'' command continues execution by moving into the method on the next line. To put it in another way, the command takes us deeper into the method. Following our example, the ''step'' command would take us into ''method3'' at which point we would be asked what to do next. The following screenshot demonstrates our example:

[[File:Step.jpg]]

=== The Next command: ===
:The ''next'' command runs the current line and moves to the next line in the current context. If the next line in the code is a method call, then unlike the ''step'' method the execution does not go deeper into the method. Following our example, if we execute the above code, the execution stop at the ''binding.pry'' line and the debugger asks us for the further action. On using the ''next'' command, the execution moves to the next line that is '' new_products = method3(seller)'' without going deeper into the method. The debugger now waits for another instruction from the programmer and if the command is ''next'' again, the debugger simply goes to the next line of code after executing the method. Thus, all the code within the ''method3'' method (which would otherwise be many steps), has been concluded with a single use of the ''next'' command. The example could be seen in the following screenshot:

[[File:Next.jpg]]

=== The Finish command: ===
:Now once we have stepped into a method using the ''step'' command, the debugger would ask us what needs to be done next. Now if we want to jump to the end of the method without the debugger asking us our choice of navigation command at the end of each line, we could use the ''finish'' command. The ''finish'' command would execute the code in the method and return back to the point from where the method was called. In our example, while the debugger is in ''method3'', the ''finish'' command would complete the code execution in ''method3'' and return back to ''method2''.

=== The Continue command: ===
:With this command we can abandon the pry session and continue the normal execution of the program. If the interpreter encounters another ''binding.pry'', a pry session is again opened. This can be incredibly annoying, since our program will stop and we’ll have to navigate the debugger every single time, so we’ll probably want to type exit-program to cancel the effect of any following ''binding.pry'' statements, thereby exiting our rails application.

=== Breakpoints: ===
:You could set or change the breakpoints in a program directly using Pry. The ''break'' command is used for this purpose. You could set breakpoints in the current file, or in any other file, or a method. Conditional breakpoints could also be changed or set using optional expressions.

:Command to display the list of breakpoints and conditional breakpoints:
<pre>
break --condition 4 x > 2 Change condition on breakpoint #4 to 'x > 2'.
break --condition 6 Remove the condition on breakpoint #6.
break List all breakpoints. (Same as `breakpoints`)
break --show 2 Show details about breakpoint #2.
</pre>
:Setting breakpoints:
<pre>
break 5 Break at line 5 in the current file.
break <class_name>#run Break at the start of `<class_name>#run`.
break app/models/test.rb:4 Break at line 4 in test.rb.
</pre>
:Deleting breakpoints:
<pre>
break --delete 5 Delete breakpoint #5.
break --disable-all Disable all breakpoints.
</pre>

=== The Edit command: ===
:You could edit the code in a file by just switching to the editor rather than having to end the Pry session. This could be done using the ''edit'' command<ref>http://kgrz.io/pry/2014/02/07/Prys-edit-command.html</ref>. On using the ''edit'' command, a new editor window pops up thereby enabling the programmer to edit the code. However, you need to specify the type of editor in the ''.pryrc'' file. For example, in order to edit the code using a Notepad editor, you need to specify the following in the ''.pryrc'' file:
<pre>
Pry.config.editor = 'Notepad'
</pre>
[[File:SnOutput1.jpg]]

=== View the documentation or source for a method: ===
:You sometimes would want to know how a particular method works or what kind of arguments it takes. The ''show-doc'' method could help you determine that. Also, you would want to know the source of the method. This could be done using the ''show-method'' command.
<pre>
pry(main)> def foo
pry(main)* puts "Welcome to the foo!!"
pry(main)* end
=> nil
pry(main)> show-method foo

From: (pry) @ line 3:
Number of lines: 3
Owner: Object
Visibility: private

def foo
puts "Welcome to the foo!!"
end
</pre>

=== List of other commonly used commands: ===
:The other list of commands could be found by typing ''help''<ref>https://github.com/pry/pry/wiki/Command-system#Help_command</ref>. The following shows other list of commands:

[[File:Help1.jpg]]

:Interested people can learn more about using Pry as a debugger by watching the video [http://www.youtube.com/watch?v=o90CCPjcIKE tutorial].

= Remote Debugging<ref>http://wiki.freepascal.org/Remote_Debugging</ref> =
:So far, Pry has been a good tool to digging into the code and checking how the code is actually working and what is exactly going on inside the code. We used ''binding.pry'' inside the program where the execution stops and the user is asked to give further instructions. However, there are situations where the execution of the program would not stop and the would not allow you to inspect the code especially in situations when [https://github.com/yegrb/yeg-wiki/wiki/Managing-application-processes-with-the-Foreman-gem Foreman] is used to manage processes. In such situation, ''pry-remote'' could be of help.

:When a process that is being run by Foreman comes across ''binding.pry'', it would halt but a Pry session would not be opened. You would be forced to kill the process as the application actually freezes. Thus, in such cases ''pry-remote'' would be a great solution and in order to work around with this, you need to first install the gem:
<pre>
gem install pry-remote
</pre>
:Then run bundler:
<pre>
bundle install
</pre>
:Once you have installed ''pry-remote'', a breakpoint can be added using ''binding.remote_pry'' anywhere in the program from where the code needs to be debugged.
<pre>
def index
binding.remote_pry
...
end
end

</pre>
:''Pry-remote'' would block your program when it hits the ''binding.remote_pry'' and open a Drb endpoint that a client can connect to<ref>http://www.ruby-doc.org/stdlib-1.9.3/libdoc/drb/rdoc/DRb.html</ref>. Running pry-remote in a shell will then connect to the session. You would then be able to interact with Pry as you would normally do. You could unblock the program by using ''exit''.

= Comparison with other debugging tools =
Pry is a replacement for Ruby's default REPL,irb. It has many more additional features as compared to irb. Some of the features that provide Pry an edge over the other debugging tools are as follows:
:*Pry enables code or syntax highlighting, auto identation and a runtime debugging console.
:*It has the ability to load any portion of the file in your text editor directly into the REPL session.
[http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html This website has a lot of comparison between Pry Debugger with other debuggers available in market.]

= Reference =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 sn

2014-09-25T22:50:43Z

Samirajk: /* Introduction to Pry debugger */

= '''Debugging in Rails using Pry''' =

Debugging is a process of finding and reducing the bugs or defects in a computer program thereby making it behave as expected. Few of the debugging techniques are [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Print debugging] (also known as printf debugging), Log debugging and Interactive debugging<ref>http://rubylearning.com/satishtalim/ruby_logging.html</ref><ref>http://object.io/site/2011/getting-to-know-ruby-debugger/</ref>.
[http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] provides a range of options to make debugging<ref>http://en.wikipedia.org/wiki/Debugging</ref> easier which include debug helpers, loggers, graphical debuggers, Pry, and so on<ref>http://guides.rubyonrails.org/debugging_rails_applications.html</ref>. In the following sections, debugging in rails using PRY is being explained.

__TOC__

= Introduction to Pry debugger =

:Pry is an [http://en.wikipedia.org/wiki/Shell_(computing) interactive shell] for the Ruby programming language. Pry could be started at any point within a running program. Due to this, programmers can inspect the program, correct the source code, or change its current state without having to restart the process. Pry is thus notable for its ability to start a [http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop REPL] within a running program.

:Pry has many features that make it extremely efficient to use. One of the example here could be Pry's ''hist --grep'' that makes it easy to search through your Pry history. Also, Pry uses the filesystem metaphor for exposing most of its introspective capabilities such as the ''ls'' command to list the methods and variables and the ''cd'' command to start interacting with a particular object.

:To start a debugging session, the ''require 'pry' '' and ''binding.pry'' lines need to be included in the program that needs to be debugged. The line ''binding.pry'' could be inserted at any point in your program. Whenever the Ruby interpreter executes this line, it opens a Pry REPL session. The code after the ''binding.pry'' statement is not executed unless instructed by the programmer. Changes could be made to fix the code and then return to running program from same point.

== Installation ==

:To use Pry for debugging a Rails application, you first need to download and install Pry-debugger. If you are using Ruby version 2.0 or higher, then download pry-debugger from [https://github.com/deivid-rodriguez/pry-byebug here]. If you are using Ruby version 1.9 or lower, then download pry-debugger from [https://rubygems.org/gems/pry-debugger here].

:To install the debugger use the following command:<ref>http://pryrepl.org/</ref>
<pre>
gem install pry-debugger.gem
</pre>
:Include the following line of code on the gem file:
<pre>
gem 'pry-rails', :group => :development
</pre>
:Once that is done, the necessary dependencies could be installed using the following command:
<pre>
$bundle install
</pre>

= Execution Commands =
:To use the execution command, invoke pry normally. There is no need to start your script or application differently. For the sake of clarity in explanation, we would refer to the program below:
<pre>
require 'pry'
def method1 (seller)
puts 'Inside method 1'
method2(seller)
end

def method2(seller)
binding.pry # Execution will stop here.
new_products = method3(seller)
puts 'After calling method3'
end

def method3(seller)
puts 'Inside method 3'
puts 'Continuing in method 3'
end

method1('xyz')

</pre>

=== The Step command: ===
:The ''step'' command continues execution by moving into the method on the next line. To put it in another way, the command takes us deeper into the method. Following our example, the ''step'' command would take us into ''method3'' at which point we would be asked what to do next. The following screenshot demonstrates our example:

[[File:Step.jpg]]

=== The Next command: ===
:The ''next'' command runs the current line and moves to the next line in the current context. If the next line in the code is a method call, then unlike the ''step'' method the execution does not go deeper into the method. Following our example, if we execute the above code, the execution stop at the ''binding.pry'' line and the debugger asks us for the further action. On using the ''next'' command, the execution moves to the next line that is '' new_products = method3(seller)'' without going deeper into the method. The debugger now waits for another instruction from the programmer and if the command is ''next'' again, the debugger simply goes to the next line of code after executing the method. Thus, all the code within the ''method3'' method (which would otherwise be many steps), has been concluded with a single use of the ''next'' command. The example could be seen in the following screenshot:

[[File:Next.jpg]]

=== The Finish command: ===
:Now once we have stepped into a method using the ''step'' command, the debugger would ask us what needs to be done next. Now if we want to jump to the end of the method without the debugger asking us our choice of navigation command at the end of each line, we could use the ''finish'' command. The ''finish'' command would execute the code in the method and return back to the point from where the method was called. In our example, while the debugger is in ''method3'', the ''finish'' command would complete the code execution in ''method3'' and return back to ''method2''.

=== The Continue command: ===
:With this command we can abandon the pry session and continue the normal execution of the program. If the interpreter encounters another ''binding.pry'', a pry session is again opened. This can be incredibly annoying, since our program will stop and we’ll have to navigate the debugger every single time, so we’ll probably want to type exit-program to cancel the effect of any following ''binding.pry'' statements, thereby exiting our rails application.

=== Breakpoints: ===
:You could set or change the breakpoints in a program directly using Pry. The ''break'' command is used for this purpose. You could set breakpoints in the current file, or in any other file, or a method. Conditional breakpoints could also be changed or set using optional expressions.

:Command to display the list of breakpoints and conditional breakpoints:
<pre>
break --condition 4 x > 2 Change condition on breakpoint #4 to 'x > 2'.
break --condition 6 Remove the condition on breakpoint #6.
break List all breakpoints. (Same as `breakpoints`)
break --show 2 Show details about breakpoint #2.
</pre>
:Setting breakpoints:
<pre>
break 5 Break at line 5 in the current file.
break <class_name>#run Break at the start of `<class_name>#run`.
break app/models/test.rb:4 Break at line 4 in test.rb.
</pre>
:Deleting breakpoints:
<pre>
break --delete 5 Delete breakpoint #5.
break --disable-all Disable all breakpoints.
</pre>

=== The Edit command: ===
:You could edit the code in a file by just switching to the editor rather than having to end the Pry session. This could be done using the ''edit'' command<ref>http://kgrz.io/pry/2014/02/07/Prys-edit-command.html</ref>. On using the ''edit'' command, a new editor window pops up thereby enabling the programmer to edit the code. However, you need to specify the type of editor in the ''.pryrc'' file. For example, in order to edit the code using a Notepad editor, you need to specify the following in the ''.pryrc'' file:
<pre>
Pry.config.editor = 'Notepad'
</pre>
[[File:SnOutput1.jpg]]

=== View the documentation or source for a method: ===
:You sometimes would want to know how a particular method works or what kind of arguments it takes. The ''show-doc'' method could help you determine that. Also, you would want to know the source of the method. This could be done using the ''show-method'' command.
<pre>
pry(main)> def foo
pry(main)* puts "Welcome to the foo!!"
pry(main)* end
=> nil
pry(main)> show-method foo

From: (pry) @ line 3:
Number of lines: 3
Owner: Object
Visibility: private

def foo
puts "Welcome to the foo!!"
end
</pre>

=== List of other commonly used commands: ===
:The other list of commands could be found by typing ''help''<ref>https://github.com/pry/pry/wiki/Command-system#Help_command</ref>. The following shows other list of commands:

[[File:Help1.jpg]]

:Interested people can learn more about using Pry as a debugger by watching this video [http://www.youtube.com/watch?v=o90CCPjcIKE tutorial].

= Remote Debugging<ref>http://wiki.freepascal.org/Remote_Debugging</ref> =
:So far, Pry has been a good tool to digging into the code and checking how the code is actually working and what is exactly going on inside the code. We used ''binding.pry'' inside the program where the execution stops and the user is asked to give further instructions. However, there are situations where the execution of the program would not stop and the would not allow you to inspect the code especially in situations when [https://github.com/yegrb/yeg-wiki/wiki/Managing-application-processes-with-the-Foreman-gem Foreman] is used to manage processes. In such situation, ''pry-remote'' could be of help.

:When a process that is being run by Foreman comes across ''binding.pry'', it would halt but a Pry session would not be opened. You would be forced to kill the process as the application actually freezes. Thus, in such cases ''pry-remote'' would be a great solution and in order to work around with this, you need to first install the gem:
<pre>
gem install pry-remote
</pre>
:Then run bundler:
<pre>
bundle install
</pre>
:Once you have installed ''pry-remote'', a breakpoint can be added using ''binding.remote_pry'' anywhere in the program from where the code needs to be debugged.
<pre>
def index
binding.remote_pry
...
end
end

</pre>
:''Pry-remote'' would block your program when it hits the ''binding.remote_pry'' and open a Drb endpoint that a client can connect to<ref>http://www.ruby-doc.org/stdlib-1.9.3/libdoc/drb/rdoc/DRb.html</ref>. Running pry-remote in a shell will then connect to the session. You would then be able to interact with Pry as you would normally do. You could unblock the program by using ''exit''.

= Comparison with other debugging tools =
Pry is a replacement for Ruby's default REPL,irb. It has many more additional features as compared to irb. Some of the features that provide Pry an edge over the other debugging tools are as follows:
:*Pry enables code or syntax highlighting, auto identation and a runtime debugging console.
:*It has the ability to load any portion of the file in your text editor directly into the REPL session.
[http://www.jackkinsella.ie/2014/06/06/debugging-rails-with-pry-debugger.html This website has a lot of comparison between Pry Debugger with other debuggers available in market.]

= Reference =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 sn

2014-09-19T20:53:11Z

Samirajk: /* Debugging in Rails using Pry */

= '''Debugging in Rails using Pry''' =

Debugging is a process of finding and reducing the bugs or defects in a computer program thereby making it behave as expected. Few of the debugging techniques are [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Print debugging] (also known as printf debugging), Log debugging and Interactive debugging<ref>http://rubylearning.com/satishtalim/ruby_logging.html</ref><ref>http://object.io/site/2011/getting-to-know-ruby-debugger/</ref>.
[http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] provides a range of options to make debugging<ref>http://en.wikipedia.org/wiki/Debugging</ref> easier which include debug helpers, loggers, graphical debuggers, Pry, and so on<ref>http://guides.rubyonrails.org/debugging_rails_applications.html</ref>. In the following sections, we would be discussing about debugging in Rails using Pry.

__TOC__

= Introduction to Pry debugger =

:Pry is an [http://en.wikipedia.org/wiki/Shell_(computing) interactive shell] for the Ruby programming language. Pry could be started at any point within a running program. Due to this, programmers can inspect the program, correct the source code, or change its current state without having to restart the process. Pry is thus notable for its ability to start a [http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop REPL] within a running program.

:Pry has many features that make it extremely efficient to use. One of the example here could be Pry's ''hist --grep'' that makes it easy to search through your Pry history. Also, Pry uses the filesystem metaphor for exposing most of its introspective capabilities such as the ''ls'' command to list the methods and variables and the ''cd'' command to start interacting with a particular object.

:To start a debugging session, you need to include the ''require 'pry' '' and ''binding.pry'' lines in your program that needs to be debugged. You could insert the line ''binding.pry'' at any point in your program. Whenever the Ruby interpreter executes this line, it opens a Pry REPL session. The code after the ''binding.pry'' statement is not executed unless instructed by the programmer. We could make changes to fix the code and then return to running program from same point.

== Installation ==

:To use Pry for debugging a Rails application, you first need to download and install Pry-debugger. If you are using Ruby version 2.0 or higher, then download pry-debugger from [https://github.com/deivid-rodriguez/pry-byebug here]. If you are using Ruby version 1.9 or lower, then download pry-debugger from [https://rubygems.org/gems/pry-debugger here].

:To install the debugger use the following command:<ref>http://pryrepl.org/</ref>
<pre>
gem install pry-debugger.gem
</pre>
:Include the following line of code on the gem file:
<pre>
gem 'pry-rails', :group => :development
</pre>
:Once that is done, the necessary dependencies could be installed using the following command:
<pre>
$bundle install
</pre>

= Execution Commands =
:To use the execution command, invoke pry normally. There is no need to start your script or application differently. For the sake of clarity in explanation, we would refer to the program below:
<pre>
require 'pry'
def method1 (seller)
puts 'Inside method 1'
method2(seller)
end

def method2(seller)
binding.pry # Execution will stop here.
new_products = method3(seller)
puts 'After calling method3'
end

def method3(seller)
puts 'Inside method 3'
puts 'Continuing in method 3'
end

method1('xyz')

</pre>

=== The Step command: ===
:The ''step'' command continues execution by moving into the method on the next line. To put it in another way, the command takes us deeper into the method. Following our example, the ''step'' command would take us into ''method3'' at which point we would be asked what to do next. The following screenshot demonstrates our example:

[[File:Step.jpg]]

=== The Next command: ===
:The ''next'' command runs the current line and moves to the next line in the current context. If the next line in the code is a method call, then unlike the ''step'' method the execution does not go deeper into the method. Following our example, if we execute the above code, the execution stop at the ''binding.pry'' line and the debugger asks us for the further action. On using the ''next'' command, the execution moves to the next line that is '' new_products = method3(seller)'' without going deeper into the method. The debugger now waits for another instruction from the programmer and if the command is ''next'' again, the debugger simply goes to the next line of code after executing the method. Thus, all the code within the ''method3'' method (which would otherwise be many steps), has been concluded with a single use of the ''next'' command. The example could be seen in the following screenshot:

[[File:Next.jpg]]

=== The Finish command: ===
:Now once we have stepped into a method using the ''step'' command, the debugger would ask us what needs to be done next. Now if we want to jump to the end of the method without the debugger asking us our choice of navigation command at the end of each line, we could use the ''finish'' command. The ''finish'' command would execute the code in the method and return back to the point from where the method was called. In our example, while the debugger is in ''method3'', the ''finish'' command would complete the code execution in ''method3'' and return back to ''method2''.

=== The Continue command: ===
:With this command we can abandon the pry session and continue the normal execution of the program. If the interpreter encounters another ''binding.pry'', a pry session is again opened. This can be incredibly annoying, since our program will stop and we’ll have to navigate the debugger every single time, so we’ll probably want to type exit-program to cancel the effect of any following ''binding.pry'' statements, thereby exiting our rails application.

=== Breakpoints: ===
:You could set or change the breakpoints in a program directly using Pry. The ''break'' command is used for this purpose. You could set breakpoints in the current file, or in any other file, or a method. Conditional breakpoints could also be changed or set using optional expressions.

:Command to display the list of breakpoints and conditional breakpoints:
<pre>
break --condition 4 x > 2 Change condition on breakpoint #4 to 'x > 2'.
break --condition 6 Remove the condition on breakpoint #6.
break List all breakpoints. (Same as `breakpoints`)
break --show 2 Show details about breakpoint #2.
</pre>
:Setting breakpoints:
<pre>
break 5 Break at line 5 in the current file.
break <class_name>#run Break at the start of `<class_name>#run`.
break app/models/test.rb:4 Break at line 4 in test.rb.
</pre>
:Deleting breakpoints:
<pre>
break --delete 5 Delete breakpoint #5.
break --disable-all Disable all breakpoints.
</pre>

=== The Edit command: ===
:You could edit the code in a file by just switching to the editor rather than having to end the Pry session. This could be done using the ''edit'' command<ref>http://kgrz.io/pry/2014/02/07/Prys-edit-command.html</ref>. On using the ''edit'' command, a new editor window pops up thereby enabling the programmer to edit the code. However, you need to specify the type of editor in the ''.pryrc'' file. For example, in order to edit the code using a Notepad editor, you need to specify the following in the ''.pryrc'' file:
<pre>
Pry.config.editor = 'Notepad'
</pre>
[[File:SnOutput1.jpg]]

=== View the documentation or source for a method: ===
:You sometimes would want to know how a particular method works or what kind of arguments it takes. The ''show-doc'' method could help you determine that. Also, you would want to know the source of the method. This could be done using the ''show-method'' command.
<pre>
pry(main)> def foo
pry(main)* puts "Welcome to the foo!!"
pry(main)* end
=> nil
pry(main)> show-method foo

From: (pry) @ line 3:
Number of lines: 3
Owner: Object
Visibility: private

def foo
puts "Welcome to the foo!!"
end
</pre>

=== List of other commonly used commands: ===
:The other list of commands could be found by typing ''help''<ref>https://github.com/pry/pry/wiki/Command-system#Help_command</ref>. The following shows other list of commands:

[[File:Help1.jpg]]

= Remote Debugging<ref>http://wiki.freepascal.org/Remote_Debugging</ref> =
:So far, Pry has been a good tool to digging into the code and checking how the code is actually working and what is exactly going on inside the code. We used ''binding.pry'' inside the program where the execution stops and the user is asked to give further instructions. However, there are situations where the execution of the program would not stop and the would not allow you to inspect the code especially in situations when [https://github.com/yegrb/yeg-wiki/wiki/Managing-application-processes-with-the-Foreman-gem Foreman] is used to manage processes. In such situation, ''pry-remote'' could be of help.

:When a process that is being run by Foreman comes across ''binding.pry'', it would halt but a Pry session would not be opened. You would be forced to kill the process as the application actually freezes. Thus, in such cases ''pry-remote'' would be a great solution and in order to work around with this, you need to first install the gem:
<pre>
gem install pry-remote
</pre>
:Then run bundler:
<pre>
bundle install
</pre>
:Once you have installed ''pry-remote'', a breakpoint can be added using ''binding.remote_pry'' anywhere in the program from where the code needs to be debugged.
<pre>
def index
binding.remote_pry
...
end
end

</pre>
:''Pry-remote'' would block your program when it hits the ''binding.remote_pry'' and open a Drb endpoint that a client can connect to<ref>http://www.ruby-doc.org/stdlib-1.9.3/libdoc/drb/rdoc/DRb.html</ref>. Running pry-remote in a shell will then connect to the session. You would then be able to interact with Pry as you would normally do. You could unblock the program by using ''exit''.

= Comparison with other debugging tools =
Pry is a replacement for Ruby's default REPL,irb. It has many more additional features as compared to irb. Some of the features that provide Pry an edge over the other debugging tools are as follows:
:*Pry enables code or syntax highlighting, auto identation and a runtime debugging console.
:*It has the ability to load any portion of the file in your text editor directly into the REPL session.

= Reference =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 sn

2014-09-19T20:51:51Z

Samirajk: /* View the documentation or source for a method: */

= '''Debugging in Rails using Pry''' =

Debugging is a process of finding and reducing the bugs or defects in a computer program thereby making it behave as expected. Few of the debugging techniques are [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Print debugging] (also known as printf debugging), Log debugging and Interactive debugging<ref>http://rubylearning.com/satishtalim/ruby_logging.html</ref><ref>http://object.io/site/2011/getting-to-know-ruby-debugger/</ref>.
[http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] provides a range of options to make debugging easier which include debug helpers, loggers, graphical debuggers, Pry, and so on<ref>http://guides.rubyonrails.org/debugging_rails_applications.html</ref>. In the following sections, we would be discussing about debugging in Rails using Pry.

__TOC__

= Introduction to Pry debugger =

:Pry is an [http://en.wikipedia.org/wiki/Shell_(computing) interactive shell] for the Ruby programming language. Pry could be started at any point within a running program. Due to this, programmers can inspect the program, correct the source code, or change its current state without having to restart the process. Pry is thus notable for its ability to start a [http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop REPL] within a running program.

:Pry has many features that make it extremely efficient to use. One of the example here could be Pry's ''hist --grep'' that makes it easy to search through your Pry history. Also, Pry uses the filesystem metaphor for exposing most of its introspective capabilities such as the ''ls'' command to list the methods and variables and the ''cd'' command to start interacting with a particular object.

:To start a debugging session, you need to include the ''require 'pry' '' and ''binding.pry'' lines in your program that needs to be debugged. You could insert the line ''binding.pry'' at any point in your program. Whenever the Ruby interpreter executes this line, it opens a Pry REPL session. The code after the ''binding.pry'' statement is not executed unless instructed by the programmer. We could make changes to fix the code and then return to running program from same point.

== Installation ==

:To use Pry for debugging a Rails application, you first need to download and install Pry-debugger. If you are using Ruby version 2.0 or higher, then download pry-debugger from [https://github.com/deivid-rodriguez/pry-byebug here]. If you are using Ruby version 1.9 or lower, then download pry-debugger from [https://rubygems.org/gems/pry-debugger here].

:To install the debugger use the following command:<ref>http://pryrepl.org/</ref>
<pre>
gem install pry-debugger.gem
</pre>
:Include the following line of code on the gem file:
<pre>
gem 'pry-rails', :group => :development
</pre>
:Once that is done, the necessary dependencies could be installed using the following command:
<pre>
$bundle install
</pre>

= Execution Commands =
:To use the execution command, invoke pry normally. There is no need to start your script or application differently. For the sake of clarity in explanation, we would refer to the program below:
<pre>
require 'pry'
def method1 (seller)
puts 'Inside method 1'
method2(seller)
end

def method2(seller)
binding.pry # Execution will stop here.
new_products = method3(seller)
puts 'After calling method3'
end

def method3(seller)
puts 'Inside method 3'
puts 'Continuing in method 3'
end

method1('xyz')

</pre>

=== The Step command: ===
:The ''step'' command continues execution by moving into the method on the next line. To put it in another way, the command takes us deeper into the method. Following our example, the ''step'' command would take us into ''method3'' at which point we would be asked what to do next. The following screenshot demonstrates our example:

[[File:Step.jpg]]

=== The Next command: ===
:The ''next'' command runs the current line and moves to the next line in the current context. If the next line in the code is a method call, then unlike the ''step'' method the execution does not go deeper into the method. Following our example, if we execute the above code, the execution stop at the ''binding.pry'' line and the debugger asks us for the further action. On using the ''next'' command, the execution moves to the next line that is '' new_products = method3(seller)'' without going deeper into the method. The debugger now waits for another instruction from the programmer and if the command is ''next'' again, the debugger simply goes to the next line of code after executing the method. Thus, all the code within the ''method3'' method (which would otherwise be many steps), has been concluded with a single use of the ''next'' command. The example could be seen in the following screenshot:

[[File:Next.jpg]]

=== The Finish command: ===
:Now once we have stepped into a method using the ''step'' command, the debugger would ask us what needs to be done next. Now if we want to jump to the end of the method without the debugger asking us our choice of navigation command at the end of each line, we could use the ''finish'' command. The ''finish'' command would execute the code in the method and return back to the point from where the method was called. In our example, while the debugger is in ''method3'', the ''finish'' command would complete the code execution in ''method3'' and return back to ''method2''.

=== The Continue command: ===
:With this command we can abandon the pry session and continue the normal execution of the program. If the interpreter encounters another ''binding.pry'', a pry session is again opened. This can be incredibly annoying, since our program will stop and we’ll have to navigate the debugger every single time, so we’ll probably want to type exit-program to cancel the effect of any following ''binding.pry'' statements, thereby exiting our rails application.

=== Breakpoints: ===
:You could set or change the breakpoints in a program directly using Pry. The ''break'' command is used for this purpose. You could set breakpoints in the current file, or in any other file, or a method. Conditional breakpoints could also be changed or set using optional expressions.

:Command to display the list of breakpoints and conditional breakpoints:
<pre>
break --condition 4 x > 2 Change condition on breakpoint #4 to 'x > 2'.
break --condition 6 Remove the condition on breakpoint #6.
break List all breakpoints. (Same as `breakpoints`)
break --show 2 Show details about breakpoint #2.
</pre>
:Setting breakpoints:
<pre>
break 5 Break at line 5 in the current file.
break <class_name>#run Break at the start of `<class_name>#run`.
break app/models/test.rb:4 Break at line 4 in test.rb.
</pre>
:Deleting breakpoints:
<pre>
break --delete 5 Delete breakpoint #5.
break --disable-all Disable all breakpoints.
</pre>

=== The Edit command: ===
:You could edit the code in a file by just switching to the editor rather than having to end the Pry session. This could be done using the ''edit'' command<ref>http://kgrz.io/pry/2014/02/07/Prys-edit-command.html</ref>. On using the ''edit'' command, a new editor window pops up thereby enabling the programmer to edit the code. However, you need to specify the type of editor in the ''.pryrc'' file. For example, in order to edit the code using a Notepad editor, you need to specify the following in the ''.pryrc'' file:
<pre>
Pry.config.editor = 'Notepad'
</pre>
[[File:SnOutput1.jpg]]

=== View the documentation or source for a method: ===
:You sometimes would want to know how a particular method works or what kind of arguments it takes. The ''show-doc'' method could help you determine that. Also, you would want to know the source of the method. This could be done using the ''show-method'' command.
<pre>
pry(main)> def foo
pry(main)* puts "Welcome to the foo!!"
pry(main)* end
=> nil
pry(main)> show-method foo

From: (pry) @ line 3:
Number of lines: 3
Owner: Object
Visibility: private

def foo
puts "Welcome to the foo!!"
end
</pre>

=== List of other commonly used commands: ===
:The other list of commands could be found by typing ''help''<ref>https://github.com/pry/pry/wiki/Command-system#Help_command</ref>. The following shows other list of commands:

[[File:Help1.jpg]]

= Remote Debugging<ref>http://wiki.freepascal.org/Remote_Debugging</ref> =
:So far, Pry has been a good tool to digging into the code and checking how the code is actually working and what is exactly going on inside the code. We used ''binding.pry'' inside the program where the execution stops and the user is asked to give further instructions. However, there are situations where the execution of the program would not stop and the would not allow you to inspect the code especially in situations when [https://github.com/yegrb/yeg-wiki/wiki/Managing-application-processes-with-the-Foreman-gem Foreman] is used to manage processes. In such situation, ''pry-remote'' could be of help.

:When a process that is being run by Foreman comes across ''binding.pry'', it would halt but a Pry session would not be opened. You would be forced to kill the process as the application actually freezes. Thus, in such cases ''pry-remote'' would be a great solution and in order to work around with this, you need to first install the gem:
<pre>
gem install pry-remote
</pre>
:Then run bundler:
<pre>
bundle install
</pre>
:Once you have installed ''pry-remote'', a breakpoint can be added using ''binding.remote_pry'' anywhere in the program from where the code needs to be debugged.
<pre>
def index
binding.remote_pry
...
end
end

</pre>
:''Pry-remote'' would block your program when it hits the ''binding.remote_pry'' and open a Drb endpoint that a client can connect to<ref>http://www.ruby-doc.org/stdlib-1.9.3/libdoc/drb/rdoc/DRb.html</ref>. Running pry-remote in a shell will then connect to the session. You would then be able to interact with Pry as you would normally do. You could unblock the program by using ''exit''.

= Comparison with other debugging tools =
Pry is a replacement for Ruby's default REPL,irb. It has many more additional features as compared to irb. Some of the features that provide Pry an edge over the other debugging tools are as follows:
:*Pry enables code or syntax highlighting, auto identation and a runtime debugging console.
:*It has the ability to load any portion of the file in your text editor directly into the REPL session.

= Reference =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 sn

2014-09-19T20:51:09Z

Samirajk: /* The Continue command: */

= '''Debugging in Rails using Pry''' =

Debugging is a process of finding and reducing the bugs or defects in a computer program thereby making it behave as expected. Few of the debugging techniques are [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Print debugging] (also known as printf debugging), Log debugging and Interactive debugging<ref>http://rubylearning.com/satishtalim/ruby_logging.html</ref><ref>http://object.io/site/2011/getting-to-know-ruby-debugger/</ref>.
[http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] provides a range of options to make debugging easier which include debug helpers, loggers, graphical debuggers, Pry, and so on<ref>http://guides.rubyonrails.org/debugging_rails_applications.html</ref>. In the following sections, we would be discussing about debugging in Rails using Pry.

__TOC__

= Introduction to Pry debugger =

:Pry is an [http://en.wikipedia.org/wiki/Shell_(computing) interactive shell] for the Ruby programming language. Pry could be started at any point within a running program. Due to this, programmers can inspect the program, correct the source code, or change its current state without having to restart the process. Pry is thus notable for its ability to start a [http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop REPL] within a running program.

:Pry has many features that make it extremely efficient to use. One of the example here could be Pry's ''hist --grep'' that makes it easy to search through your Pry history. Also, Pry uses the filesystem metaphor for exposing most of its introspective capabilities such as the ''ls'' command to list the methods and variables and the ''cd'' command to start interacting with a particular object.

:To start a debugging session, you need to include the ''require 'pry' '' and ''binding.pry'' lines in your program that needs to be debugged. You could insert the line ''binding.pry'' at any point in your program. Whenever the Ruby interpreter executes this line, it opens a Pry REPL session. The code after the ''binding.pry'' statement is not executed unless instructed by the programmer. We could make changes to fix the code and then return to running program from same point.

== Installation ==

:To use Pry for debugging a Rails application, you first need to download and install Pry-debugger. If you are using Ruby version 2.0 or higher, then download pry-debugger from [https://github.com/deivid-rodriguez/pry-byebug here]. If you are using Ruby version 1.9 or lower, then download pry-debugger from [https://rubygems.org/gems/pry-debugger here].

:To install the debugger use the following command:<ref>http://pryrepl.org/</ref>
<pre>
gem install pry-debugger.gem
</pre>
:Include the following line of code on the gem file:
<pre>
gem 'pry-rails', :group => :development
</pre>
:Once that is done, the necessary dependencies could be installed using the following command:
<pre>
$bundle install
</pre>

= Execution Commands =
:To use the execution command, invoke pry normally. There is no need to start your script or application differently. For the sake of clarity in explanation, we would refer to the program below:
<pre>
require 'pry'
def method1 (seller)
puts 'Inside method 1'
method2(seller)
end

def method2(seller)
binding.pry # Execution will stop here.
new_products = method3(seller)
puts 'After calling method3'
end

def method3(seller)
puts 'Inside method 3'
puts 'Continuing in method 3'
end

method1('xyz')

</pre>

=== The Step command: ===
:The ''step'' command continues execution by moving into the method on the next line. To put it in another way, the command takes us deeper into the method. Following our example, the ''step'' command would take us into ''method3'' at which point we would be asked what to do next. The following screenshot demonstrates our example:

[[File:Step.jpg]]

=== The Next command: ===
:The ''next'' command runs the current line and moves to the next line in the current context. If the next line in the code is a method call, then unlike the ''step'' method the execution does not go deeper into the method. Following our example, if we execute the above code, the execution stop at the ''binding.pry'' line and the debugger asks us for the further action. On using the ''next'' command, the execution moves to the next line that is '' new_products = method3(seller)'' without going deeper into the method. The debugger now waits for another instruction from the programmer and if the command is ''next'' again, the debugger simply goes to the next line of code after executing the method. Thus, all the code within the ''method3'' method (which would otherwise be many steps), has been concluded with a single use of the ''next'' command. The example could be seen in the following screenshot:

[[File:Next.jpg]]

=== The Finish command: ===
:Now once we have stepped into a method using the ''step'' command, the debugger would ask us what needs to be done next. Now if we want to jump to the end of the method without the debugger asking us our choice of navigation command at the end of each line, we could use the ''finish'' command. The ''finish'' command would execute the code in the method and return back to the point from where the method was called. In our example, while the debugger is in ''method3'', the ''finish'' command would complete the code execution in ''method3'' and return back to ''method2''.

=== The Continue command: ===
:With this command we can abandon the pry session and continue the normal execution of the program. If the interpreter encounters another ''binding.pry'', a pry session is again opened. This can be incredibly annoying, since our program will stop and we’ll have to navigate the debugger every single time, so we’ll probably want to type exit-program to cancel the effect of any following ''binding.pry'' statements, thereby exiting our rails application.

=== Breakpoints: ===
:You could set or change the breakpoints in a program directly using Pry. The ''break'' command is used for this purpose. You could set breakpoints in the current file, or in any other file, or a method. Conditional breakpoints could also be changed or set using optional expressions.

:Command to display the list of breakpoints and conditional breakpoints:
<pre>
break --condition 4 x > 2 Change condition on breakpoint #4 to 'x > 2'.
break --condition 6 Remove the condition on breakpoint #6.
break List all breakpoints. (Same as `breakpoints`)
break --show 2 Show details about breakpoint #2.
</pre>
:Setting breakpoints:
<pre>
break 5 Break at line 5 in the current file.
break <class_name>#run Break at the start of `<class_name>#run`.
break app/models/test.rb:4 Break at line 4 in test.rb.
</pre>
:Deleting breakpoints:
<pre>
break --delete 5 Delete breakpoint #5.
break --disable-all Disable all breakpoints.
</pre>

=== The Edit command: ===
:You could edit the code in a file by just switching to the editor rather than having to end the Pry session. This could be done using the ''edit'' command<ref>http://kgrz.io/pry/2014/02/07/Prys-edit-command.html</ref>. On using the ''edit'' command, a new editor window pops up thereby enabling the programmer to edit the code. However, you need to specify the type of editor in the ''.pryrc'' file. For example, in order to edit the code using a Notepad editor, you need to specify the following in the ''.pryrc'' file:
<pre>
Pry.config.editor = 'Notepad'
</pre>
[[File:SnOutput1.jpg]]

=== View the documentation or source for a method: ===
:You sometimes would want to know how a particular method works or what kind of arguments it takes. The 'show-doc' method could help you determine that. Also, you would want to know the source of the method. This could be done using the ''show-method'' command.
<pre>
pry(main)> def foo
pry(main)* puts "Welcome to the foo!!"
pry(main)* end
=> nil
pry(main)> show-method foo

From: (pry) @ line 3:
Number of lines: 3
Owner: Object
Visibility: private

def foo
puts "Welcome to the foo!!"
end
</pre>

=== List of other commonly used commands: ===
:The other list of commands could be found by typing ''help''<ref>https://github.com/pry/pry/wiki/Command-system#Help_command</ref>. The following shows other list of commands:

[[File:Help1.jpg]]

= Remote Debugging<ref>http://wiki.freepascal.org/Remote_Debugging</ref> =
:So far, Pry has been a good tool to digging into the code and checking how the code is actually working and what is exactly going on inside the code. We used ''binding.pry'' inside the program where the execution stops and the user is asked to give further instructions. However, there are situations where the execution of the program would not stop and the would not allow you to inspect the code especially in situations when [https://github.com/yegrb/yeg-wiki/wiki/Managing-application-processes-with-the-Foreman-gem Foreman] is used to manage processes. In such situation, ''pry-remote'' could be of help.

:When a process that is being run by Foreman comes across ''binding.pry'', it would halt but a Pry session would not be opened. You would be forced to kill the process as the application actually freezes. Thus, in such cases ''pry-remote'' would be a great solution and in order to work around with this, you need to first install the gem:
<pre>
gem install pry-remote
</pre>
:Then run bundler:
<pre>
bundle install
</pre>
:Once you have installed ''pry-remote'', a breakpoint can be added using ''binding.remote_pry'' anywhere in the program from where the code needs to be debugged.
<pre>
def index
binding.remote_pry
...
end
end

</pre>
:''Pry-remote'' would block your program when it hits the ''binding.remote_pry'' and open a Drb endpoint that a client can connect to<ref>http://www.ruby-doc.org/stdlib-1.9.3/libdoc/drb/rdoc/DRb.html</ref>. Running pry-remote in a shell will then connect to the session. You would then be able to interact with Pry as you would normally do. You could unblock the program by using ''exit''.

= Comparison with other debugging tools =
Pry is a replacement for Ruby's default REPL,irb. It has many more additional features as compared to irb. Some of the features that provide Pry an edge over the other debugging tools are as follows:
:*Pry enables code or syntax highlighting, auto identation and a runtime debugging console.
:*It has the ability to load any portion of the file in your text editor directly into the REPL session.

= Reference =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 sn

2014-09-19T20:50:30Z

Samirajk: /* The Finish command: */

= '''Debugging in Rails using Pry''' =

Debugging is a process of finding and reducing the bugs or defects in a computer program thereby making it behave as expected. Few of the debugging techniques are [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Print debugging] (also known as printf debugging), Log debugging and Interactive debugging<ref>http://rubylearning.com/satishtalim/ruby_logging.html</ref><ref>http://object.io/site/2011/getting-to-know-ruby-debugger/</ref>.
[http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] provides a range of options to make debugging easier which include debug helpers, loggers, graphical debuggers, Pry, and so on<ref>http://guides.rubyonrails.org/debugging_rails_applications.html</ref>. In the following sections, we would be discussing about debugging in Rails using Pry.

__TOC__

= Introduction to Pry debugger =

:Pry is an [http://en.wikipedia.org/wiki/Shell_(computing) interactive shell] for the Ruby programming language. Pry could be started at any point within a running program. Due to this, programmers can inspect the program, correct the source code, or change its current state without having to restart the process. Pry is thus notable for its ability to start a [http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop REPL] within a running program.

:Pry has many features that make it extremely efficient to use. One of the example here could be Pry's ''hist --grep'' that makes it easy to search through your Pry history. Also, Pry uses the filesystem metaphor for exposing most of its introspective capabilities such as the ''ls'' command to list the methods and variables and the ''cd'' command to start interacting with a particular object.

:To start a debugging session, you need to include the ''require 'pry' '' and ''binding.pry'' lines in your program that needs to be debugged. You could insert the line ''binding.pry'' at any point in your program. Whenever the Ruby interpreter executes this line, it opens a Pry REPL session. The code after the ''binding.pry'' statement is not executed unless instructed by the programmer. We could make changes to fix the code and then return to running program from same point.

== Installation ==

:To use Pry for debugging a Rails application, you first need to download and install Pry-debugger. If you are using Ruby version 2.0 or higher, then download pry-debugger from [https://github.com/deivid-rodriguez/pry-byebug here]. If you are using Ruby version 1.9 or lower, then download pry-debugger from [https://rubygems.org/gems/pry-debugger here].

:To install the debugger use the following command:<ref>http://pryrepl.org/</ref>
<pre>
gem install pry-debugger.gem
</pre>
:Include the following line of code on the gem file:
<pre>
gem 'pry-rails', :group => :development
</pre>
:Once that is done, the necessary dependencies could be installed using the following command:
<pre>
$bundle install
</pre>

= Execution Commands =
:To use the execution command, invoke pry normally. There is no need to start your script or application differently. For the sake of clarity in explanation, we would refer to the program below:
<pre>
require 'pry'
def method1 (seller)
puts 'Inside method 1'
method2(seller)
end

def method2(seller)
binding.pry # Execution will stop here.
new_products = method3(seller)
puts 'After calling method3'
end

def method3(seller)
puts 'Inside method 3'
puts 'Continuing in method 3'
end

method1('xyz')

</pre>

=== The Step command: ===
:The ''step'' command continues execution by moving into the method on the next line. To put it in another way, the command takes us deeper into the method. Following our example, the ''step'' command would take us into ''method3'' at which point we would be asked what to do next. The following screenshot demonstrates our example:

[[File:Step.jpg]]

=== The Next command: ===
:The ''next'' command runs the current line and moves to the next line in the current context. If the next line in the code is a method call, then unlike the ''step'' method the execution does not go deeper into the method. Following our example, if we execute the above code, the execution stop at the ''binding.pry'' line and the debugger asks us for the further action. On using the ''next'' command, the execution moves to the next line that is '' new_products = method3(seller)'' without going deeper into the method. The debugger now waits for another instruction from the programmer and if the command is ''next'' again, the debugger simply goes to the next line of code after executing the method. Thus, all the code within the ''method3'' method (which would otherwise be many steps), has been concluded with a single use of the ''next'' command. The example could be seen in the following screenshot:

[[File:Next.jpg]]

=== The Finish command: ===
:Now once we have stepped into a method using the ''step'' command, the debugger would ask us what needs to be done next. Now if we want to jump to the end of the method without the debugger asking us our choice of navigation command at the end of each line, we could use the ''finish'' command. The ''finish'' command would execute the code in the method and return back to the point from where the method was called. In our example, while the debugger is in ''method3'', the ''finish'' command would complete the code execution in ''method3'' and return back to ''method2''.

=== The Continue command: ===
:With this command we can abandon the pry session and continue the normal execution of the program. If the interpreter encounters another 'binding.pry', a pry session is again opened. This can be incredibly annoying, since our program will stop and we’ll have to navigate the debugger every single time, so we’ll probably want to type exit-program to cancel the effect of any following binding.pry statements, thereby exiting our rails application.

=== Breakpoints: ===
:You could set or change the breakpoints in a program directly using Pry. The ''break'' command is used for this purpose. You could set breakpoints in the current file, or in any other file, or a method. Conditional breakpoints could also be changed or set using optional expressions.

:Command to display the list of breakpoints and conditional breakpoints:
<pre>
break --condition 4 x > 2 Change condition on breakpoint #4 to 'x > 2'.
break --condition 6 Remove the condition on breakpoint #6.
break List all breakpoints. (Same as `breakpoints`)
break --show 2 Show details about breakpoint #2.
</pre>
:Setting breakpoints:
<pre>
break 5 Break at line 5 in the current file.
break <class_name>#run Break at the start of `<class_name>#run`.
break app/models/test.rb:4 Break at line 4 in test.rb.
</pre>
:Deleting breakpoints:
<pre>
break --delete 5 Delete breakpoint #5.
break --disable-all Disable all breakpoints.
</pre>

=== The Edit command: ===
:You could edit the code in a file by just switching to the editor rather than having to end the Pry session. This could be done using the ''edit'' command<ref>http://kgrz.io/pry/2014/02/07/Prys-edit-command.html</ref>. On using the ''edit'' command, a new editor window pops up thereby enabling the programmer to edit the code. However, you need to specify the type of editor in the ''.pryrc'' file. For example, in order to edit the code using a Notepad editor, you need to specify the following in the ''.pryrc'' file:
<pre>
Pry.config.editor = 'Notepad'
</pre>
[[File:SnOutput1.jpg]]

=== View the documentation or source for a method: ===
:You sometimes would want to know how a particular method works or what kind of arguments it takes. The 'show-doc' method could help you determine that. Also, you would want to know the source of the method. This could be done using the ''show-method'' command.
<pre>
pry(main)> def foo
pry(main)* puts "Welcome to the foo!!"
pry(main)* end
=> nil
pry(main)> show-method foo

From: (pry) @ line 3:
Number of lines: 3
Owner: Object
Visibility: private

def foo
puts "Welcome to the foo!!"
end
</pre>

=== List of other commonly used commands: ===
:The other list of commands could be found by typing ''help''<ref>https://github.com/pry/pry/wiki/Command-system#Help_command</ref>. The following shows other list of commands:

[[File:Help1.jpg]]

= Remote Debugging<ref>http://wiki.freepascal.org/Remote_Debugging</ref> =
:So far, Pry has been a good tool to digging into the code and checking how the code is actually working and what is exactly going on inside the code. We used ''binding.pry'' inside the program where the execution stops and the user is asked to give further instructions. However, there are situations where the execution of the program would not stop and the would not allow you to inspect the code especially in situations when [https://github.com/yegrb/yeg-wiki/wiki/Managing-application-processes-with-the-Foreman-gem Foreman] is used to manage processes. In such situation, ''pry-remote'' could be of help.

:When a process that is being run by Foreman comes across ''binding.pry'', it would halt but a Pry session would not be opened. You would be forced to kill the process as the application actually freezes. Thus, in such cases ''pry-remote'' would be a great solution and in order to work around with this, you need to first install the gem:
<pre>
gem install pry-remote
</pre>
:Then run bundler:
<pre>
bundle install
</pre>
:Once you have installed ''pry-remote'', a breakpoint can be added using ''binding.remote_pry'' anywhere in the program from where the code needs to be debugged.
<pre>
def index
binding.remote_pry
...
end
end

</pre>
:''Pry-remote'' would block your program when it hits the ''binding.remote_pry'' and open a Drb endpoint that a client can connect to<ref>http://www.ruby-doc.org/stdlib-1.9.3/libdoc/drb/rdoc/DRb.html</ref>. Running pry-remote in a shell will then connect to the session. You would then be able to interact with Pry as you would normally do. You could unblock the program by using ''exit''.

= Comparison with other debugging tools =
Pry is a replacement for Ruby's default REPL,irb. It has many more additional features as compared to irb. Some of the features that provide Pry an edge over the other debugging tools are as follows:
:*Pry enables code or syntax highlighting, auto identation and a runtime debugging console.
:*It has the ability to load any portion of the file in your text editor directly into the REPL session.

= Reference =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 sn

2014-09-19T20:49:24Z

Samirajk: /* The Step command: */

= '''Debugging in Rails using Pry''' =

Debugging is a process of finding and reducing the bugs or defects in a computer program thereby making it behave as expected. Few of the debugging techniques are [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Print debugging] (also known as printf debugging), Log debugging and Interactive debugging<ref>http://rubylearning.com/satishtalim/ruby_logging.html</ref><ref>http://object.io/site/2011/getting-to-know-ruby-debugger/</ref>.
[http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] provides a range of options to make debugging easier which include debug helpers, loggers, graphical debuggers, Pry, and so on<ref>http://guides.rubyonrails.org/debugging_rails_applications.html</ref>. In the following sections, we would be discussing about debugging in Rails using Pry.

__TOC__

= Introduction to Pry debugger =

:Pry is an [http://en.wikipedia.org/wiki/Shell_(computing) interactive shell] for the Ruby programming language. Pry could be started at any point within a running program. Due to this, programmers can inspect the program, correct the source code, or change its current state without having to restart the process. Pry is thus notable for its ability to start a [http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop REPL] within a running program.

:Pry has many features that make it extremely efficient to use. One of the example here could be Pry's ''hist --grep'' that makes it easy to search through your Pry history. Also, Pry uses the filesystem metaphor for exposing most of its introspective capabilities such as the ''ls'' command to list the methods and variables and the ''cd'' command to start interacting with a particular object.

:To start a debugging session, you need to include the ''require 'pry' '' and ''binding.pry'' lines in your program that needs to be debugged. You could insert the line ''binding.pry'' at any point in your program. Whenever the Ruby interpreter executes this line, it opens a Pry REPL session. The code after the ''binding.pry'' statement is not executed unless instructed by the programmer. We could make changes to fix the code and then return to running program from same point.

== Installation ==

:To use Pry for debugging a Rails application, you first need to download and install Pry-debugger. If you are using Ruby version 2.0 or higher, then download pry-debugger from [https://github.com/deivid-rodriguez/pry-byebug here]. If you are using Ruby version 1.9 or lower, then download pry-debugger from [https://rubygems.org/gems/pry-debugger here].

:To install the debugger use the following command:<ref>http://pryrepl.org/</ref>
<pre>
gem install pry-debugger.gem
</pre>
:Include the following line of code on the gem file:
<pre>
gem 'pry-rails', :group => :development
</pre>
:Once that is done, the necessary dependencies could be installed using the following command:
<pre>
$bundle install
</pre>

= Execution Commands =
:To use the execution command, invoke pry normally. There is no need to start your script or application differently. For the sake of clarity in explanation, we would refer to the program below:
<pre>
require 'pry'
def method1 (seller)
puts 'Inside method 1'
method2(seller)
end

def method2(seller)
binding.pry # Execution will stop here.
new_products = method3(seller)
puts 'After calling method3'
end

def method3(seller)
puts 'Inside method 3'
puts 'Continuing in method 3'
end

method1('xyz')

</pre>

=== The Step command: ===
:The ''step'' command continues execution by moving into the method on the next line. To put it in another way, the command takes us deeper into the method. Following our example, the ''step'' command would take us into ''method3'' at which point we would be asked what to do next. The following screenshot demonstrates our example:

[[File:Step.jpg]]

=== The Next command: ===
:The ''next'' command runs the current line and moves to the next line in the current context. If the next line in the code is a method call, then unlike the ''step'' method the execution does not go deeper into the method. Following our example, if we execute the above code, the execution stop at the ''binding.pry'' line and the debugger asks us for the further action. On using the ''next'' command, the execution moves to the next line that is '' new_products = method3(seller)'' without going deeper into the method. The debugger now waits for another instruction from the programmer and if the command is ''next'' again, the debugger simply goes to the next line of code after executing the method. Thus, all the code within the ''method3'' method (which would otherwise be many steps), has been concluded with a single use of the ''next'' command. The example could be seen in the following screenshot:

[[File:Next.jpg]]

=== The Finish command: ===
:Now once we have stepped into a method using the 'step' command, the debugger would ask us what needs to be done next. Now if we want to jump to the end of the method without the debugger asking us our choice of navigation command at the end of each line, we could use the 'finish' command. The finish command would execute the code in the method and return back to the point from where the method was called. In our example, while the debugger is in method3, the finish command would complete the code execution in method3 and return back to method2.

=== The Continue command: ===
:With this command we can abandon the pry session and continue the normal execution of the program. If the interpreter encounters another 'binding.pry', a pry session is again opened. This can be incredibly annoying, since our program will stop and we’ll have to navigate the debugger every single time, so we’ll probably want to type exit-program to cancel the effect of any following binding.pry statements, thereby exiting our rails application.

=== Breakpoints: ===
:You could set or change the breakpoints in a program directly using Pry. The ''break'' command is used for this purpose. You could set breakpoints in the current file, or in any other file, or a method. Conditional breakpoints could also be changed or set using optional expressions.

:Command to display the list of breakpoints and conditional breakpoints:
<pre>
break --condition 4 x > 2 Change condition on breakpoint #4 to 'x > 2'.
break --condition 6 Remove the condition on breakpoint #6.
break List all breakpoints. (Same as `breakpoints`)
break --show 2 Show details about breakpoint #2.
</pre>
:Setting breakpoints:
<pre>
break 5 Break at line 5 in the current file.
break <class_name>#run Break at the start of `<class_name>#run`.
break app/models/test.rb:4 Break at line 4 in test.rb.
</pre>
:Deleting breakpoints:
<pre>
break --delete 5 Delete breakpoint #5.
break --disable-all Disable all breakpoints.
</pre>

=== The Edit command: ===
:You could edit the code in a file by just switching to the editor rather than having to end the Pry session. This could be done using the ''edit'' command<ref>http://kgrz.io/pry/2014/02/07/Prys-edit-command.html</ref>. On using the ''edit'' command, a new editor window pops up thereby enabling the programmer to edit the code. However, you need to specify the type of editor in the ''.pryrc'' file. For example, in order to edit the code using a Notepad editor, you need to specify the following in the ''.pryrc'' file:
<pre>
Pry.config.editor = 'Notepad'
</pre>
[[File:SnOutput1.jpg]]

=== View the documentation or source for a method: ===
:You sometimes would want to know how a particular method works or what kind of arguments it takes. The 'show-doc' method could help you determine that. Also, you would want to know the source of the method. This could be done using the ''show-method'' command.
<pre>
pry(main)> def foo
pry(main)* puts "Welcome to the foo!!"
pry(main)* end
=> nil
pry(main)> show-method foo

From: (pry) @ line 3:
Number of lines: 3
Owner: Object
Visibility: private

def foo
puts "Welcome to the foo!!"
end
</pre>

=== List of other commonly used commands: ===
:The other list of commands could be found by typing ''help''<ref>https://github.com/pry/pry/wiki/Command-system#Help_command</ref>. The following shows other list of commands:

[[File:Help1.jpg]]

= Remote Debugging<ref>http://wiki.freepascal.org/Remote_Debugging</ref> =
:So far, Pry has been a good tool to digging into the code and checking how the code is actually working and what is exactly going on inside the code. We used ''binding.pry'' inside the program where the execution stops and the user is asked to give further instructions. However, there are situations where the execution of the program would not stop and the would not allow you to inspect the code especially in situations when [https://github.com/yegrb/yeg-wiki/wiki/Managing-application-processes-with-the-Foreman-gem Foreman] is used to manage processes. In such situation, ''pry-remote'' could be of help.

:When a process that is being run by Foreman comes across ''binding.pry'', it would halt but a Pry session would not be opened. You would be forced to kill the process as the application actually freezes. Thus, in such cases ''pry-remote'' would be a great solution and in order to work around with this, you need to first install the gem:
<pre>
gem install pry-remote
</pre>
:Then run bundler:
<pre>
bundle install
</pre>
:Once you have installed ''pry-remote'', a breakpoint can be added using ''binding.remote_pry'' anywhere in the program from where the code needs to be debugged.
<pre>
def index
binding.remote_pry
...
end
end

</pre>
:''Pry-remote'' would block your program when it hits the ''binding.remote_pry'' and open a Drb endpoint that a client can connect to<ref>http://www.ruby-doc.org/stdlib-1.9.3/libdoc/drb/rdoc/DRb.html</ref>. Running pry-remote in a shell will then connect to the session. You would then be able to interact with Pry as you would normally do. You could unblock the program by using ''exit''.

= Comparison with other debugging tools =
Pry is a replacement for Ruby's default REPL,irb. It has many more additional features as compared to irb. Some of the features that provide Pry an edge over the other debugging tools are as follows:
:*Pry enables code or syntax highlighting, auto identation and a runtime debugging console.
:*It has the ability to load any portion of the file in your text editor directly into the REPL session.

= Reference =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 sn

2014-09-19T20:49:03Z

Samirajk: /* The Step command: */

= '''Debugging in Rails using Pry''' =

Debugging is a process of finding and reducing the bugs or defects in a computer program thereby making it behave as expected. Few of the debugging techniques are [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Print debugging] (also known as printf debugging), Log debugging and Interactive debugging<ref>http://rubylearning.com/satishtalim/ruby_logging.html</ref><ref>http://object.io/site/2011/getting-to-know-ruby-debugger/</ref>.
[http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] provides a range of options to make debugging easier which include debug helpers, loggers, graphical debuggers, Pry, and so on<ref>http://guides.rubyonrails.org/debugging_rails_applications.html</ref>. In the following sections, we would be discussing about debugging in Rails using Pry.

__TOC__

= Introduction to Pry debugger =

:Pry is an [http://en.wikipedia.org/wiki/Shell_(computing) interactive shell] for the Ruby programming language. Pry could be started at any point within a running program. Due to this, programmers can inspect the program, correct the source code, or change its current state without having to restart the process. Pry is thus notable for its ability to start a [http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop REPL] within a running program.

:Pry has many features that make it extremely efficient to use. One of the example here could be Pry's ''hist --grep'' that makes it easy to search through your Pry history. Also, Pry uses the filesystem metaphor for exposing most of its introspective capabilities such as the ''ls'' command to list the methods and variables and the ''cd'' command to start interacting with a particular object.

:To start a debugging session, you need to include the ''require 'pry' '' and ''binding.pry'' lines in your program that needs to be debugged. You could insert the line ''binding.pry'' at any point in your program. Whenever the Ruby interpreter executes this line, it opens a Pry REPL session. The code after the ''binding.pry'' statement is not executed unless instructed by the programmer. We could make changes to fix the code and then return to running program from same point.

== Installation ==

:To use Pry for debugging a Rails application, you first need to download and install Pry-debugger. If you are using Ruby version 2.0 or higher, then download pry-debugger from [https://github.com/deivid-rodriguez/pry-byebug here]. If you are using Ruby version 1.9 or lower, then download pry-debugger from [https://rubygems.org/gems/pry-debugger here].

:To install the debugger use the following command:<ref>http://pryrepl.org/</ref>
<pre>
gem install pry-debugger.gem
</pre>
:Include the following line of code on the gem file:
<pre>
gem 'pry-rails', :group => :development
</pre>
:Once that is done, the necessary dependencies could be installed using the following command:
<pre>
$bundle install
</pre>

= Execution Commands =
:To use the execution command, invoke pry normally. There is no need to start your script or application differently. For the sake of clarity in explanation, we would refer to the program below:
<pre>
require 'pry'
def method1 (seller)
puts 'Inside method 1'
method2(seller)
end

def method2(seller)
binding.pry # Execution will stop here.
new_products = method3(seller)
puts 'After calling method3'
end

def method3(seller)
puts 'Inside method 3'
puts 'Continuing in method 3'
end

method1('xyz')

</pre>

=== The Step command: ===
:The ''step'' command continues execution by moving into the method on the next line. To put it in another way, the command takes us deeper into the method. Following our example, the ''step'' command would take us into 'method3' at which point we would be asked what to do next. The following screenshot demonstrates our example:

[[File:Step.jpg]]

=== The Next command: ===
:The ''next'' command runs the current line and moves to the next line in the current context. If the next line in the code is a method call, then unlike the ''step'' method the execution does not go deeper into the method. Following our example, if we execute the above code, the execution stop at the ''binding.pry'' line and the debugger asks us for the further action. On using the ''next'' command, the execution moves to the next line that is '' new_products = method3(seller)'' without going deeper into the method. The debugger now waits for another instruction from the programmer and if the command is ''next'' again, the debugger simply goes to the next line of code after executing the method. Thus, all the code within the ''method3'' method (which would otherwise be many steps), has been concluded with a single use of the ''next'' command. The example could be seen in the following screenshot:

[[File:Next.jpg]]

=== The Finish command: ===
:Now once we have stepped into a method using the 'step' command, the debugger would ask us what needs to be done next. Now if we want to jump to the end of the method without the debugger asking us our choice of navigation command at the end of each line, we could use the 'finish' command. The finish command would execute the code in the method and return back to the point from where the method was called. In our example, while the debugger is in method3, the finish command would complete the code execution in method3 and return back to method2.

=== The Continue command: ===
:With this command we can abandon the pry session and continue the normal execution of the program. If the interpreter encounters another 'binding.pry', a pry session is again opened. This can be incredibly annoying, since our program will stop and we’ll have to navigate the debugger every single time, so we’ll probably want to type exit-program to cancel the effect of any following binding.pry statements, thereby exiting our rails application.

=== Breakpoints: ===
:You could set or change the breakpoints in a program directly using Pry. The ''break'' command is used for this purpose. You could set breakpoints in the current file, or in any other file, or a method. Conditional breakpoints could also be changed or set using optional expressions.

:Command to display the list of breakpoints and conditional breakpoints:
<pre>
break --condition 4 x > 2 Change condition on breakpoint #4 to 'x > 2'.
break --condition 6 Remove the condition on breakpoint #6.
break List all breakpoints. (Same as `breakpoints`)
break --show 2 Show details about breakpoint #2.
</pre>
:Setting breakpoints:
<pre>
break 5 Break at line 5 in the current file.
break <class_name>#run Break at the start of `<class_name>#run`.
break app/models/test.rb:4 Break at line 4 in test.rb.
</pre>
:Deleting breakpoints:
<pre>
break --delete 5 Delete breakpoint #5.
break --disable-all Disable all breakpoints.
</pre>

=== The Edit command: ===
:You could edit the code in a file by just switching to the editor rather than having to end the Pry session. This could be done using the ''edit'' command<ref>http://kgrz.io/pry/2014/02/07/Prys-edit-command.html</ref>. On using the ''edit'' command, a new editor window pops up thereby enabling the programmer to edit the code. However, you need to specify the type of editor in the ''.pryrc'' file. For example, in order to edit the code using a Notepad editor, you need to specify the following in the ''.pryrc'' file:
<pre>
Pry.config.editor = 'Notepad'
</pre>
[[File:SnOutput1.jpg]]

=== View the documentation or source for a method: ===
:You sometimes would want to know how a particular method works or what kind of arguments it takes. The 'show-doc' method could help you determine that. Also, you would want to know the source of the method. This could be done using the ''show-method'' command.
<pre>
pry(main)> def foo
pry(main)* puts "Welcome to the foo!!"
pry(main)* end
=> nil
pry(main)> show-method foo

From: (pry) @ line 3:
Number of lines: 3
Owner: Object
Visibility: private

def foo
puts "Welcome to the foo!!"
end
</pre>

=== List of other commonly used commands: ===
:The other list of commands could be found by typing ''help''<ref>https://github.com/pry/pry/wiki/Command-system#Help_command</ref>. The following shows other list of commands:

[[File:Help1.jpg]]

= Remote Debugging<ref>http://wiki.freepascal.org/Remote_Debugging</ref> =
:So far, Pry has been a good tool to digging into the code and checking how the code is actually working and what is exactly going on inside the code. We used ''binding.pry'' inside the program where the execution stops and the user is asked to give further instructions. However, there are situations where the execution of the program would not stop and the would not allow you to inspect the code especially in situations when [https://github.com/yegrb/yeg-wiki/wiki/Managing-application-processes-with-the-Foreman-gem Foreman] is used to manage processes. In such situation, ''pry-remote'' could be of help.

:When a process that is being run by Foreman comes across ''binding.pry'', it would halt but a Pry session would not be opened. You would be forced to kill the process as the application actually freezes. Thus, in such cases ''pry-remote'' would be a great solution and in order to work around with this, you need to first install the gem:
<pre>
gem install pry-remote
</pre>
:Then run bundler:
<pre>
bundle install
</pre>
:Once you have installed ''pry-remote'', a breakpoint can be added using ''binding.remote_pry'' anywhere in the program from where the code needs to be debugged.
<pre>
def index
binding.remote_pry
...
end
end

</pre>
:''Pry-remote'' would block your program when it hits the ''binding.remote_pry'' and open a Drb endpoint that a client can connect to<ref>http://www.ruby-doc.org/stdlib-1.9.3/libdoc/drb/rdoc/DRb.html</ref>. Running pry-remote in a shell will then connect to the session. You would then be able to interact with Pry as you would normally do. You could unblock the program by using ''exit''.

= Comparison with other debugging tools =
Pry is a replacement for Ruby's default REPL,irb. It has many more additional features as compared to irb. Some of the features that provide Pry an edge over the other debugging tools are as follows:
:*Pry enables code or syntax highlighting, auto identation and a runtime debugging console.
:*It has the ability to load any portion of the file in your text editor directly into the REPL session.

= Reference =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 sn

2014-09-19T20:46:18Z

Samirajk: /* Remote Debugginghttp://wiki.freepascal.org/Remote_Debugging */

= '''Debugging in Rails using Pry''' =

Debugging is a process of finding and reducing the bugs or defects in a computer program thereby making it behave as expected. Few of the debugging techniques are [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Print debugging] (also known as printf debugging), Log debugging and Interactive debugging<ref>http://rubylearning.com/satishtalim/ruby_logging.html</ref><ref>http://object.io/site/2011/getting-to-know-ruby-debugger/</ref>.
[http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] provides a range of options to make debugging easier which include debug helpers, loggers, graphical debuggers, Pry, and so on<ref>http://guides.rubyonrails.org/debugging_rails_applications.html</ref>. In the following sections, we would be discussing about debugging in Rails using Pry.

__TOC__

= Introduction to Pry debugger =

:Pry is an [http://en.wikipedia.org/wiki/Shell_(computing) interactive shell] for the Ruby programming language. Pry could be started at any point within a running program. Due to this, programmers can inspect the program, correct the source code, or change its current state without having to restart the process. Pry is thus notable for its ability to start a [http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop REPL] within a running program.

:Pry has many features that make it extremely efficient to use. One of the example here could be Pry's ''hist --grep'' that makes it easy to search through your Pry history. Also, Pry uses the filesystem metaphor for exposing most of its introspective capabilities such as the ''ls'' command to list the methods and variables and the ''cd'' command to start interacting with a particular object.

:To start a debugging session, you need to include the ''require 'pry' '' and ''binding.pry'' lines in your program that needs to be debugged. You could insert the line ''binding.pry'' at any point in your program. Whenever the Ruby interpreter executes this line, it opens a Pry REPL session. The code after the ''binding.pry'' statement is not executed unless instructed by the programmer. We could make changes to fix the code and then return to running program from same point.

== Installation ==

:To use Pry for debugging a Rails application, you first need to download and install Pry-debugger. If you are using Ruby version 2.0 or higher, then download pry-debugger from [https://github.com/deivid-rodriguez/pry-byebug here]. If you are using Ruby version 1.9 or lower, then download pry-debugger from [https://rubygems.org/gems/pry-debugger here].

:To install the debugger use the following command:<ref>http://pryrepl.org/</ref>
<pre>
gem install pry-debugger.gem
</pre>
:Include the following line of code on the gem file:
<pre>
gem 'pry-rails', :group => :development
</pre>
:Once that is done, the necessary dependencies could be installed using the following command:
<pre>
$bundle install
</pre>

= Execution Commands =
:To use the execution command, invoke pry normally. There is no need to start your script or application differently. For the sake of clarity in explanation, we would refer to the program below:
<pre>
require 'pry'
def method1 (seller)
puts 'Inside method 1'
method2(seller)
end

def method2(seller)
binding.pry # Execution will stop here.
new_products = method3(seller)
puts 'After calling method3'
end

def method3(seller)
puts 'Inside method 3'
puts 'Continuing in method 3'
end

method1('xyz')

</pre>

=== The Step command: ===
:The ''step'' command continues execution by moving into the method on the next line. To put it in another way, the command takes us deeper into the method. Following our example, the step command would take us into 'method3' at which point we would be asked what to do next. The following screenshot demonstrates our example:

[[File:Step.jpg]]

=== The Next command: ===
:The ''next'' command runs the current line and moves to the next line in the current context. If the next line in the code is a method call, then unlike the ''step'' method the execution does not go deeper into the method. Following our example, if we execute the above code, the execution stop at the ''binding.pry'' line and the debugger asks us for the further action. On using the ''next'' command, the execution moves to the next line that is '' new_products = method3(seller)'' without going deeper into the method. The debugger now waits for another instruction from the programmer and if the command is ''next'' again, the debugger simply goes to the next line of code after executing the method. Thus, all the code within the ''method3'' method (which would otherwise be many steps), has been concluded with a single use of the ''next'' command. The example could be seen in the following screenshot:

[[File:Next.jpg]]

=== The Finish command: ===
:Now once we have stepped into a method using the 'step' command, the debugger would ask us what needs to be done next. Now if we want to jump to the end of the method without the debugger asking us our choice of navigation command at the end of each line, we could use the 'finish' command. The finish command would execute the code in the method and return back to the point from where the method was called. In our example, while the debugger is in method3, the finish command would complete the code execution in method3 and return back to method2.

=== The Continue command: ===
:With this command we can abandon the pry session and continue the normal execution of the program. If the interpreter encounters another 'binding.pry', a pry session is again opened. This can be incredibly annoying, since our program will stop and we’ll have to navigate the debugger every single time, so we’ll probably want to type exit-program to cancel the effect of any following binding.pry statements, thereby exiting our rails application.

=== Breakpoints: ===
:You could set or change the breakpoints in a program directly using Pry. The ''break'' command is used for this purpose. You could set breakpoints in the current file, or in any other file, or a method. Conditional breakpoints could also be changed or set using optional expressions.

:Command to display the list of breakpoints and conditional breakpoints:
<pre>
break --condition 4 x > 2 Change condition on breakpoint #4 to 'x > 2'.
break --condition 6 Remove the condition on breakpoint #6.
break List all breakpoints. (Same as `breakpoints`)
break --show 2 Show details about breakpoint #2.
</pre>
:Setting breakpoints:
<pre>
break 5 Break at line 5 in the current file.
break <class_name>#run Break at the start of `<class_name>#run`.
break app/models/test.rb:4 Break at line 4 in test.rb.
</pre>
:Deleting breakpoints:
<pre>
break --delete 5 Delete breakpoint #5.
break --disable-all Disable all breakpoints.
</pre>

=== The Edit command: ===
:You could edit the code in a file by just switching to the editor rather than having to end the Pry session. This could be done using the ''edit'' command<ref>http://kgrz.io/pry/2014/02/07/Prys-edit-command.html</ref>. On using the ''edit'' command, a new editor window pops up thereby enabling the programmer to edit the code. However, you need to specify the type of editor in the ''.pryrc'' file. For example, in order to edit the code using a Notepad editor, you need to specify the following in the ''.pryrc'' file:
<pre>
Pry.config.editor = 'Notepad'
</pre>
[[File:SnOutput1.jpg]]

=== View the documentation or source for a method: ===
:You sometimes would want to know how a particular method works or what kind of arguments it takes. The 'show-doc' method could help you determine that. Also, you would want to know the source of the method. This could be done using the ''show-method'' command.
<pre>
pry(main)> def foo
pry(main)* puts "Welcome to the foo!!"
pry(main)* end
=> nil
pry(main)> show-method foo

From: (pry) @ line 3:
Number of lines: 3
Owner: Object
Visibility: private

def foo
puts "Welcome to the foo!!"
end
</pre>

=== List of other commonly used commands: ===
:The other list of commands could be found by typing ''help''<ref>https://github.com/pry/pry/wiki/Command-system#Help_command</ref>. The following shows other list of commands:

[[File:Help1.jpg]]

= Remote Debugging<ref>http://wiki.freepascal.org/Remote_Debugging</ref> =
:So far, Pry has been a good tool to digging into the code and checking how the code is actually working and what is exactly going on inside the code. We used ''binding.pry'' inside the program where the execution stops and the user is asked to give further instructions. However, there are situations where the execution of the program would not stop and the would not allow you to inspect the code especially in situations when [https://github.com/yegrb/yeg-wiki/wiki/Managing-application-processes-with-the-Foreman-gem Foreman] is used to manage processes. In such situation, ''pry-remote'' could be of help.

:When a process that is being run by Foreman comes across ''binding.pry'', it would halt but a Pry session would not be opened. You would be forced to kill the process as the application actually freezes. Thus, in such cases ''pry-remote'' would be a great solution and in order to work around with this, you need to first install the gem:
<pre>
gem install pry-remote
</pre>
:Then run bundler:
<pre>
bundle install
</pre>
:Once you have installed ''pry-remote'', a breakpoint can be added using ''binding.remote_pry'' anywhere in the program from where the code needs to be debugged.
<pre>
def index
binding.remote_pry
...
end
end

</pre>
:''Pry-remote'' would block your program when it hits the ''binding.remote_pry'' and open a Drb endpoint that a client can connect to<ref>http://www.ruby-doc.org/stdlib-1.9.3/libdoc/drb/rdoc/DRb.html</ref>. Running pry-remote in a shell will then connect to the session. You would then be able to interact with Pry as you would normally do. You could unblock the program by using ''exit''.

= Comparison with other debugging tools =
Pry is a replacement for Ruby's default REPL,irb. It has many more additional features as compared to irb. Some of the features that provide Pry an edge over the other debugging tools are as follows:
:*Pry enables code or syntax highlighting, auto identation and a runtime debugging console.
:*It has the ability to load any portion of the file in your text editor directly into the REPL session.

= Reference =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 sn

2014-09-19T20:45:07Z

Samirajk: /* Remote Debugginghttp://wiki.freepascal.org/Remote_Debugging */

= '''Debugging in Rails using Pry''' =

Debugging is a process of finding and reducing the bugs or defects in a computer program thereby making it behave as expected. Few of the debugging techniques are [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Print debugging] (also known as printf debugging), Log debugging and Interactive debugging<ref>http://rubylearning.com/satishtalim/ruby_logging.html</ref><ref>http://object.io/site/2011/getting-to-know-ruby-debugger/</ref>.
[http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] provides a range of options to make debugging easier which include debug helpers, loggers, graphical debuggers, Pry, and so on<ref>http://guides.rubyonrails.org/debugging_rails_applications.html</ref>. In the following sections, we would be discussing about debugging in Rails using Pry.

__TOC__

= Introduction to Pry debugger =

:Pry is an [http://en.wikipedia.org/wiki/Shell_(computing) interactive shell] for the Ruby programming language. Pry could be started at any point within a running program. Due to this, programmers can inspect the program, correct the source code, or change its current state without having to restart the process. Pry is thus notable for its ability to start a [http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop REPL] within a running program.

:Pry has many features that make it extremely efficient to use. One of the example here could be Pry's ''hist --grep'' that makes it easy to search through your Pry history. Also, Pry uses the filesystem metaphor for exposing most of its introspective capabilities such as the ''ls'' command to list the methods and variables and the ''cd'' command to start interacting with a particular object.

:To start a debugging session, you need to include the ''require 'pry' '' and ''binding.pry'' lines in your program that needs to be debugged. You could insert the line ''binding.pry'' at any point in your program. Whenever the Ruby interpreter executes this line, it opens a Pry REPL session. The code after the ''binding.pry'' statement is not executed unless instructed by the programmer. We could make changes to fix the code and then return to running program from same point.

== Installation ==

:To use Pry for debugging a Rails application, you first need to download and install Pry-debugger. If you are using Ruby version 2.0 or higher, then download pry-debugger from [https://github.com/deivid-rodriguez/pry-byebug here]. If you are using Ruby version 1.9 or lower, then download pry-debugger from [https://rubygems.org/gems/pry-debugger here].

:To install the debugger use the following command:<ref>http://pryrepl.org/</ref>
<pre>
gem install pry-debugger.gem
</pre>
:Include the following line of code on the gem file:
<pre>
gem 'pry-rails', :group => :development
</pre>
:Once that is done, the necessary dependencies could be installed using the following command:
<pre>
$bundle install
</pre>

= Execution Commands =
:To use the execution command, invoke pry normally. There is no need to start your script or application differently. For the sake of clarity in explanation, we would refer to the program below:
<pre>
require 'pry'
def method1 (seller)
puts 'Inside method 1'
method2(seller)
end

def method2(seller)
binding.pry # Execution will stop here.
new_products = method3(seller)
puts 'After calling method3'
end

def method3(seller)
puts 'Inside method 3'
puts 'Continuing in method 3'
end

method1('xyz')

</pre>

=== The Step command: ===
:The ''step'' command continues execution by moving into the method on the next line. To put it in another way, the command takes us deeper into the method. Following our example, the step command would take us into 'method3' at which point we would be asked what to do next. The following screenshot demonstrates our example:

[[File:Step.jpg]]

=== The Next command: ===
:The ''next'' command runs the current line and moves to the next line in the current context. If the next line in the code is a method call, then unlike the ''step'' method the execution does not go deeper into the method. Following our example, if we execute the above code, the execution stop at the ''binding.pry'' line and the debugger asks us for the further action. On using the ''next'' command, the execution moves to the next line that is '' new_products = method3(seller)'' without going deeper into the method. The debugger now waits for another instruction from the programmer and if the command is ''next'' again, the debugger simply goes to the next line of code after executing the method. Thus, all the code within the ''method3'' method (which would otherwise be many steps), has been concluded with a single use of the ''next'' command. The example could be seen in the following screenshot:

[[File:Next.jpg]]

=== The Finish command: ===
:Now once we have stepped into a method using the 'step' command, the debugger would ask us what needs to be done next. Now if we want to jump to the end of the method without the debugger asking us our choice of navigation command at the end of each line, we could use the 'finish' command. The finish command would execute the code in the method and return back to the point from where the method was called. In our example, while the debugger is in method3, the finish command would complete the code execution in method3 and return back to method2.

=== The Continue command: ===
:With this command we can abandon the pry session and continue the normal execution of the program. If the interpreter encounters another 'binding.pry', a pry session is again opened. This can be incredibly annoying, since our program will stop and we’ll have to navigate the debugger every single time, so we’ll probably want to type exit-program to cancel the effect of any following binding.pry statements, thereby exiting our rails application.

=== Breakpoints: ===
:You could set or change the breakpoints in a program directly using Pry. The ''break'' command is used for this purpose. You could set breakpoints in the current file, or in any other file, or a method. Conditional breakpoints could also be changed or set using optional expressions.

:Command to display the list of breakpoints and conditional breakpoints:
<pre>
break --condition 4 x > 2 Change condition on breakpoint #4 to 'x > 2'.
break --condition 6 Remove the condition on breakpoint #6.
break List all breakpoints. (Same as `breakpoints`)
break --show 2 Show details about breakpoint #2.
</pre>
:Setting breakpoints:
<pre>
break 5 Break at line 5 in the current file.
break <class_name>#run Break at the start of `<class_name>#run`.
break app/models/test.rb:4 Break at line 4 in test.rb.
</pre>
:Deleting breakpoints:
<pre>
break --delete 5 Delete breakpoint #5.
break --disable-all Disable all breakpoints.
</pre>

=== The Edit command: ===
:You could edit the code in a file by just switching to the editor rather than having to end the Pry session. This could be done using the ''edit'' command<ref>http://kgrz.io/pry/2014/02/07/Prys-edit-command.html</ref>. On using the ''edit'' command, a new editor window pops up thereby enabling the programmer to edit the code. However, you need to specify the type of editor in the ''.pryrc'' file. For example, in order to edit the code using a Notepad editor, you need to specify the following in the ''.pryrc'' file:
<pre>
Pry.config.editor = 'Notepad'
</pre>
[[File:SnOutput1.jpg]]

=== View the documentation or source for a method: ===
:You sometimes would want to know how a particular method works or what kind of arguments it takes. The 'show-doc' method could help you determine that. Also, you would want to know the source of the method. This could be done using the ''show-method'' command.
<pre>
pry(main)> def foo
pry(main)* puts "Welcome to the foo!!"
pry(main)* end
=> nil
pry(main)> show-method foo

From: (pry) @ line 3:
Number of lines: 3
Owner: Object
Visibility: private

def foo
puts "Welcome to the foo!!"
end
</pre>

=== List of other commonly used commands: ===
:The other list of commands could be found by typing ''help''<ref>https://github.com/pry/pry/wiki/Command-system#Help_command</ref>. The following shows other list of commands:

[[File:Help1.jpg]]

= Remote Debugging<ref>http://wiki.freepascal.org/Remote_Debugging</ref> =
:So far, Pry has been a good tool to digging into the code and checking how the code is actually working and what is exactly going on inside the code. We used ''binding.pry'' inside the program where the execution stops and the user is asked to give further instructions. However, there are situations where the execution of the program would not stop and the would not allow you to inspect the code especially in situations when [https://github.com/yegrb/yeg-wiki/wiki/Managing-application-processes-with-the-Foreman-gem Foreman] is used to manage processes. In such situation, ''pry-remote'' could be of help.

:When a process that is being run by Foreman comes across ''binding.pry'', it would halt but a Pry session would not be opened. You would be forced to kill the process as the application actually freezes. Thus, in such cases ''pry-remote'' would be a great solution and in order to work around with this, you need to first install the gem:
<pre>
gem install pry-remote
</pre>
:Then run bundler:
<pre>
bundle install
</pre>
:Once you have installed ''pry-remote'', a breakpoint can be added using ''binding.remote_pry'' anywhere in the program from where the code needs to be debugged.
<pre>
def index
binding.remote_pry
...
end
end

</pre>
:''Pry-remote'' would block your program when it hits the ''binding.remote_pry'' and open a Drb endpoint that a client ca connect to<ref>http://www.ruby-doc.org/stdlib-1.9.3/libdoc/drb/rdoc/DRb.html</ref>. Running pry-remote in a shell will then connect to the session. You would then be able to interact with Pry as you would normally do. You could unblock the program by using ''exit''.

= Comparison with other debugging tools =
Pry is a replacement for Ruby's default REPL,irb. It has many more additional features as compared to irb. Some of the features that provide Pry an edge over the other debugging tools are as follows:
:*Pry enables code or syntax highlighting, auto identation and a runtime debugging console.
:*It has the ability to load any portion of the file in your text editor directly into the REPL session.

= Reference =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 sn

2014-09-19T20:42:27Z

Samirajk: /* The Edit command: */

= '''Debugging in Rails using Pry''' =

Debugging is a process of finding and reducing the bugs or defects in a computer program thereby making it behave as expected. Few of the debugging techniques are [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Print debugging] (also known as printf debugging), Log debugging and Interactive debugging<ref>http://rubylearning.com/satishtalim/ruby_logging.html</ref><ref>http://object.io/site/2011/getting-to-know-ruby-debugger/</ref>.
[http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] provides a range of options to make debugging easier which include debug helpers, loggers, graphical debuggers, Pry, and so on<ref>http://guides.rubyonrails.org/debugging_rails_applications.html</ref>. In the following sections, we would be discussing about debugging in Rails using Pry.

__TOC__

= Introduction to Pry debugger =

:Pry is an [http://en.wikipedia.org/wiki/Shell_(computing) interactive shell] for the Ruby programming language. Pry could be started at any point within a running program. Due to this, programmers can inspect the program, correct the source code, or change its current state without having to restart the process. Pry is thus notable for its ability to start a [http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop REPL] within a running program.

:Pry has many features that make it extremely efficient to use. One of the example here could be Pry's ''hist --grep'' that makes it easy to search through your Pry history. Also, Pry uses the filesystem metaphor for exposing most of its introspective capabilities such as the ''ls'' command to list the methods and variables and the ''cd'' command to start interacting with a particular object.

:To start a debugging session, you need to include the ''require 'pry' '' and ''binding.pry'' lines in your program that needs to be debugged. You could insert the line ''binding.pry'' at any point in your program. Whenever the Ruby interpreter executes this line, it opens a Pry REPL session. The code after the ''binding.pry'' statement is not executed unless instructed by the programmer. We could make changes to fix the code and then return to running program from same point.

== Installation ==

:To use Pry for debugging a Rails application, you first need to download and install Pry-debugger. If you are using Ruby version 2.0 or higher, then download pry-debugger from [https://github.com/deivid-rodriguez/pry-byebug here]. If you are using Ruby version 1.9 or lower, then download pry-debugger from [https://rubygems.org/gems/pry-debugger here].

:To install the debugger use the following command:<ref>http://pryrepl.org/</ref>
<pre>
gem install pry-debugger.gem
</pre>
:Include the following line of code on the gem file:
<pre>
gem 'pry-rails', :group => :development
</pre>
:Once that is done, the necessary dependencies could be installed using the following command:
<pre>
$bundle install
</pre>

= Execution Commands =
:To use the execution command, invoke pry normally. There is no need to start your script or application differently. For the sake of clarity in explanation, we would refer to the program below:
<pre>
require 'pry'
def method1 (seller)
puts 'Inside method 1'
method2(seller)
end

def method2(seller)
binding.pry # Execution will stop here.
new_products = method3(seller)
puts 'After calling method3'
end

def method3(seller)
puts 'Inside method 3'
puts 'Continuing in method 3'
end

method1('xyz')

</pre>

=== The Step command: ===
:The ''step'' command continues execution by moving into the method on the next line. To put it in another way, the command takes us deeper into the method. Following our example, the step command would take us into 'method3' at which point we would be asked what to do next. The following screenshot demonstrates our example:

[[File:Step.jpg]]

=== The Next command: ===
:The ''next'' command runs the current line and moves to the next line in the current context. If the next line in the code is a method call, then unlike the ''step'' method the execution does not go deeper into the method. Following our example, if we execute the above code, the execution stop at the ''binding.pry'' line and the debugger asks us for the further action. On using the ''next'' command, the execution moves to the next line that is '' new_products = method3(seller)'' without going deeper into the method. The debugger now waits for another instruction from the programmer and if the command is ''next'' again, the debugger simply goes to the next line of code after executing the method. Thus, all the code within the ''method3'' method (which would otherwise be many steps), has been concluded with a single use of the ''next'' command. The example could be seen in the following screenshot:

[[File:Next.jpg]]

=== The Finish command: ===
:Now once we have stepped into a method using the 'step' command, the debugger would ask us what needs to be done next. Now if we want to jump to the end of the method without the debugger asking us our choice of navigation command at the end of each line, we could use the 'finish' command. The finish command would execute the code in the method and return back to the point from where the method was called. In our example, while the debugger is in method3, the finish command would complete the code execution in method3 and return back to method2.

=== The Continue command: ===
:With this command we can abandon the pry session and continue the normal execution of the program. If the interpreter encounters another 'binding.pry', a pry session is again opened. This can be incredibly annoying, since our program will stop and we’ll have to navigate the debugger every single time, so we’ll probably want to type exit-program to cancel the effect of any following binding.pry statements, thereby exiting our rails application.

=== Breakpoints: ===
:You could set or change the breakpoints in a program directly using Pry. The ''break'' command is used for this purpose. You could set breakpoints in the current file, or in any other file, or a method. Conditional breakpoints could also be changed or set using optional expressions.

:Command to display the list of breakpoints and conditional breakpoints:
<pre>
break --condition 4 x > 2 Change condition on breakpoint #4 to 'x > 2'.
break --condition 6 Remove the condition on breakpoint #6.
break List all breakpoints. (Same as `breakpoints`)
break --show 2 Show details about breakpoint #2.
</pre>
:Setting breakpoints:
<pre>
break 5 Break at line 5 in the current file.
break <class_name>#run Break at the start of `<class_name>#run`.
break app/models/test.rb:4 Break at line 4 in test.rb.
</pre>
:Deleting breakpoints:
<pre>
break --delete 5 Delete breakpoint #5.
break --disable-all Disable all breakpoints.
</pre>

=== The Edit command: ===
:You could edit the code in a file by just switching to the editor rather than having to end the Pry session. This could be done using the ''edit'' command<ref>http://kgrz.io/pry/2014/02/07/Prys-edit-command.html</ref>. On using the ''edit'' command, a new editor window pops up thereby enabling the programmer to edit the code. However, you need to specify the type of editor in the ''.pryrc'' file. For example, in order to edit the code using a Notepad editor, you need to specify the following in the ''.pryrc'' file:
<pre>
Pry.config.editor = 'Notepad'
</pre>
[[File:SnOutput1.jpg]]

=== View the documentation or source for a method: ===
:You sometimes would want to know how a particular method works or what kind of arguments it takes. The 'show-doc' method could help you determine that. Also, you would want to know the source of the method. This could be done using the ''show-method'' command.
<pre>
pry(main)> def foo
pry(main)* puts "Welcome to the foo!!"
pry(main)* end
=> nil
pry(main)> show-method foo

From: (pry) @ line 3:
Number of lines: 3
Owner: Object
Visibility: private

def foo
puts "Welcome to the foo!!"
end
</pre>

=== List of other commonly used commands: ===
:The other list of commands could be found by typing ''help''<ref>https://github.com/pry/pry/wiki/Command-system#Help_command</ref>. The following shows other list of commands:

[[File:Help1.jpg]]

= Remote Debugging<ref>http://wiki.freepascal.org/Remote_Debugging</ref> =
:So far, Pry has been a good tool to digging into the code and checking how the code is actually working and what is exactly going on inside the code. We used ''binding.pry'' inside the program where the execution stops and the user is asked to give further instructions. However, there are situations where the execution of the program would not stop and the would not allow you to inspect the code especially in situations when [https://github.com/yegrb/yeg-wiki/wiki/Managing-application-processes-with-the-Foreman-gem Foreman] is used to manage processes. In such situation, ''pry-remote'' could be of help.

:When a process that is being run by Foreman comes across ''binding.pry'', it would halt but a Pry session would not be opened. You would be forced to kill the process as the application actually freezes. Thus, in such cases ''pry-remote'' would be a great solution and in order to work around with this, you need to first install the gem:
<pre>
gem install pry-remote
</pre>
:Then run bundler:
<pre>
bundle install
</pre>
:Once you have installed ''pry-remote'', a breakpoint can be added using ''binding.remote_pry'' anywhere in the program from where the code needs to be debugged.
<pre>
def index
binding.remote_pry
...
end
end

</pre>
:''Pry-remote'' would block your program when it hits the ''binding.remote_pry'' and open a Drb endpoint that a client ca connect to. Running pry-remote in a shell will then connect to the session. You would then be able to interact with Pry as you would normally do. You could unblock the program by using ''exit''.

= Comparison with other debugging tools =
Pry is a replacement for Ruby's default REPL,irb. It has many more additional features as compared to irb. Some of the features that provide Pry an edge over the other debugging tools are as follows:
:*Pry enables code or syntax highlighting, auto identation and a runtime debugging console.
:*It has the ability to load any portion of the file in your text editor directly into the REPL session.

= Reference =
<references />

CSC/ECE 517 Fall 2014/ch1a 26 sn

2014-09-19T02:08:25Z

Samirajk: /* List of other commonly used commands: */

= '''Debugging in Rails using Pry''' =

Debugging is a process of finding and reducing the bugs or defects in a computer program thereby making it behave as expected. Few of the debugging techniques are [http://en.wikipedia.org/wiki/Debug_code#Print_debugging Print debugging] (also known as printf debugging), Log debugging and Interactive debugging<ref>http://rubylearning.com/satishtalim/ruby_logging.html</ref><ref>http://object.io/site/2011/getting-to-know-ruby-debugger/</ref>.
[http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] provides a range of options to make debugging easier which include debug helpers, loggers, graphical debuggers, Pry, and so on<ref>http://guides.rubyonrails.org/debugging_rails_applications.html</ref>. In the following sections, we would be discussing about debugging in Rails using Pry.

__TOC__

= Introduction to Pry debugger =

:Pry is an [http://en.wikipedia.org/wiki/Shell_(computing) interactive shell] for the Ruby programming language. Pry could be started at any point within a running program. Due to this, programmers can inspect the program, correct the source code, or change its current state without having to restart the process. Pry is thus notable for its ability to start a [http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop REPL] within a running program.

:Pry has many features that make it extremely efficient to use. One of the example here could be Pry's ''hist --grep'' that makes it easy to search through your Pry history. Also, Pry uses the filesystem metaphor for exposing most of its introspective capabilities such as the ''ls'' command to list the methods and variables and the ''cd'' command to start interacting with a particular object.

:To start a debugging session, you need to include the ''require 'pry' '' and ''binding.pry'' lines in your program that needs to be debugged. You could insert the line ''binding.pry'' at any point in your program. Whenever the Ruby interpreter executes this line, it opens a Pry REPL session. The code after the ''binding.pry'' statement is not executed unless instructed by the programmer. We could make changes to fix the code and then return to running program from same point.

== Installation ==

:To use Pry for debugging a Rails application, you first need to download and install Pry-debugger. If you are using Ruby version 2.0 or higher, then download pry-debugger from [https://github.com/deivid-rodriguez/pry-byebug here]. If you are using Ruby version 1.9 or lower, then download pry-debugger from [https://rubygems.org/gems/pry-debugger here].

:To install the debugger use the following command:<ref>http://pryrepl.org/</ref>
<pre>
gem install pry-debugger.gem
</pre>
:Include the following line of code on the gem file:
<pre>
gem 'pry-rails', :group => :development
</pre>
:Once that is done, the necessary dependencies could be installed using the following command:
<pre>
$bundle install
</pre>

= Execution Commands =
:To use the execution command, invoke pry normally. There is no need to start your script or application differently. For the sake of clarity in explanation, we would refer to the program below:
<pre>
require 'pry'
def method1 (seller)
puts 'Inside method 1'
method2(seller)
end

def method2(seller)
binding.pry # Execution will stop here.
new_products = method3(seller)
puts 'After calling method3'
end

def method3(seller)
puts 'Inside method 3'
puts 'Continuing in method 3'
end

method1('xyz')

</pre>

=== The Step command: ===
:The ''step'' command continues execution by moving into the method on the next line. To put it in another way, the command takes us deeper into the method. Following our example, the step command would take us into 'method3' at which point we would be asked what to do next. The following screenshot demonstrates our example:

[[File:Step.jpg]]

=== The Next command: ===
:The ''next'' command runs the current line and moves to the next line in the current context. If the next line in the code is a method call, then unlike the ''step'' method the execution does not go deeper into the method. Following our example, if we execute the above code, the execution stop at the ''binding.pry'' line and the debugger asks us for the further action. On using the ''next'' command, the execution moves to the next line that is '' new_products = method3(seller)'' without going deeper into the method. The debugger now waits for another instruction from the programmer and if the command is ''next'' again, the debugger simply goes to the next line of code after executing the method. Thus, all the code within the ''method3'' method (which would otherwise be many steps), has been concluded with a single use of the ''next'' command. The example could be seen in the following screenshot:

[[File:Next.jpg]]

=== The Finish command: ===
:Now once we have stepped into a method using the 'step' command, the debugger would ask us what needs to be done next. Now if we want to jump to the end of the method without the debugger asking us our choice of navigation command at the end of each line, we could use the 'finish' command. The finish command would execute the code in the method and return back to the point from where the method was called. In our example, while the debugger is in method3, the finish command would complete the code execution in method3 and return back to method2.

=== The Continue command: ===
:With this command we can abandon the pry session and continue the normal execution of the program. If the interpreter encounters another 'binding.pry', a pry session is again opened. This can be incredibly annoying, since our program will stop and we’ll have to navigate the debugger every single time, so we’ll probably want to type exit-program to cancel the effect of any following binding.pry statements, thereby exiting our rails application.

=== Breakpoints: ===
:You could set or change the breakpoints in a program directly using Pry. The ''break'' command is used for this purpose. You could set breakpoints in the current file, or in any other file, or a method. Conditional breakpoints could also be changed or set using optional expressions.

:Command to display the list of breakpoints and conditional breakpoints:
<pre>
break --condition 4 x > 2 Change condition on breakpoint #4 to 'x > 2'.
break --condition 6 Remove the condition on breakpoint #6.
break List all breakpoints. (Same as `breakpoints`)
break --show 2 Show details about breakpoint #2.
</pre>
:Setting breakpoints:
<pre>
break 5 Break at line 5 in the current file.
break <class_name>#run Break at the start of `<class_name>#run`.
break app/models/test.rb:4 Break at line 4 in test.rb.
</pre>
:Deleting breakpoints:
<pre>
break --delete 5 Delete breakpoint #5.
break --disable-all Disable all breakpoints.
</pre>

=== The Edit command: ===
:You could edit the code in a file by just switching to the editor rather than having to end the Pry session. This could be done using the ''edit'' command. On using the ''edit'' command, a new editor window pops up thereby enabling the programmer to edit the code. However, you need to specify the type of editor in the ''.pryrc'' file. For example, in order to edit the code using a Notepad editor, you need to specify the following in the ''.pryrc'' file:
<pre>
Pry.config.editor = 'Notepad'
</pre>
[[File:SnOutput1.jpg]]

=== View the documentation or source for a method: ===
:You sometimes would want to know how a particular method works or what kind of arguments it takes. The 'show-doc' method could help you determine that. Also, you would want to know the source of the method. This could be done using the ''show-method'' command.
<pre>
pry(main)> def foo
pry(main)* puts "Welcome to the foo!!"
pry(main)* end
=> nil
pry(main)> show-method foo

From: (pry) @ line 3:
Number of lines: 3
Owner: Object
Visibility: private

def foo
puts "Welcome to the foo!!"
end
</pre>

=== List of other commonly used commands: ===
:The other list of commands could be found by typing ''help''<ref>https://github.com/pry/pry/wiki/Command-system#Help_command</ref>. The following shows other list of commands:

[[File:Help1.jpg]]

= Remote Debugging<ref>http://wiki.freepascal.org/Remote_Debugging</ref> =
:So far, Pry has been a good tool to digging into the code and checking how the code is actually working and what is exactly going on inside the code. We used ''binding.pry'' inside the program where the execution stops and the user is asked to give further instructions. However, there are situations where the execution of the program would not stop and the would not allow you to inspect the code especially in situations when [https://github.com/yegrb/yeg-wiki/wiki/Managing-application-processes-with-the-Foreman-gem Foreman] is used to manage processes. In such situation, ''pry-remote'' could be of help.

:When a process that is being run by Foreman comes across ''binding.pry'', it would halt but a Pry session would not be opened. You would be forced to kill the process as the application actually freezes. Thus, in such cases ''pry-remote'' would be a great solution and in order to work around with this, you need to first install the gem:
<pre>
gem install pry-remote
</pre>
:Then run bundler:
<pre>
bundle install
</pre>
:Once you have installed ''pry-remote'', a breakpoint can be added using ''binding.remote_pry'' anywhere in the program from where the code needs to be debugged.
<pre>
def index
binding.remote_pry
...
end
end

</pre>
:''Pry-remote'' would block your program when it hits the ''binding.remote_pry'' and open a Drb endpoint that a client ca connect to. Running pry-remote in a shell will then connect to the session. You would then be able to interact with Pry as you would normally do. You could unblock the program by using ''exit''.

= Comparison with other debugging tools =
Pry is a replacement for Ruby's default REPL,irb. It has many more additional features as compared to irb. Some of the features that provide Pry an edge over the other debugging tools are as follows:
:*Pry enables code or syntax highlighting, auto identation and a runtime debugging console.
:*It has the ability to load any portion of the file in your text editor directly into the REPL session.

= Reference =
<references />