@@ -1,4 +1,4 @@ -= Contributing to Rubinius +# Contributing to Rubinius There are as many ways to help with Rubinius as there are people. The following are just some ideas. Understand that Rubinius is a large, @@ -6,18 +6,30 @@ fast-moving project, so you will likely need to coordinate your efforts with others. A great deal of communication occurs on the #rubinius IRC channel. There are logs for the channel and a mailing list. See link:community.txt -## Triage tickets + +## Triage Tickets * Revive or close old tickets. * Build minimalist cases that reproduce the bugs + ## Write docs Annoy people on the channel by asking how things work. Then write them down so that the next doc writer can be annoying with other questions. + +## Fix Failing Specs + +1. Run `bin/mspec tag --list fails` to show specs tagged as failing +1. Run `bin/mspec spec/frozen/1.8/<some dir>` + + ## Write Specs +1. Run `bin/mspec tag --list incomplete` to show specs that have been tagged + as incomplete. These specs may simply need review, or there could be specs + missing for a particular class. 1. Find unspecified behaviors. Be vicious! Once you found a nice corner-case, write a spec. See 0Howto - Write a spec](/howto/write_a_spec.html) @@ -25,13 +37,15 @@ that the next doc writer can be annoying with other questions. spec:check` OR `bin/mspec -t ruby spec/ruby` to run all the specs that should pass on MatzRuby -## Run your code + +## Run Your Code Your code it often more vicious than the specs. Run your pet project under rubinius and report crashes! See [Howto - Write a ticket](/howto/write_a_ticket.html) -## Cleanup code + +## Cleanup Code Search for tags like TODO, HACK, FIXME in the code and fix them. Once you're finished, submit a ticket with the [PATCH] tag and a small description. See @@ -79,4 +93,3 @@ Q. Will you reject my patch if my style is "more Rubyesque"? A. If the patch works (e.g. does not use features that cannot be guaranteed to exist in all cases), it will not be rejected based on a stylistic qualm. The code is most welcome. But "clever" or obscure code is not. - doc/contributing.txt @@ -1,11 +1,11 @@ -= How exceptions are delivered. +# How exceptions are delivered. There are 3 separate parts 1. The exception deliver table, one per compiled method. 2. A translator that converts rescues into the exception table 3. The exception deliverer, which searches tables and perform jumps. -== The exception table. +## The exception table. This is the core of the exception deliver mechanism. The table is organized into rows, each row having 3 columns: @@ -13,7 +13,7 @@ is organized into rows, each row having 3 columns: 2. the end bytecode index 3. the bytecode index to jump to -== How they all work together +## How they all work together When an exception is raised, the deliverer takes the current context's exception table and the current ip and searches @@ -42,7 +42,7 @@ find someone to handle the exception, the cpu is trigger to handle it itself. This typically means informing the user in some way that an exception has reached the top and that the program is going to terminate. -== Algorithms +## Algorithms find an exception handler: doc/exceptions.txt @@ -1,4 +1,4 @@ -= Method Contract +# Method Contract Methods contain a contract that method implements and the caller must adhere to. Herein are pieces of the method contract. @@ -19,7 +19,7 @@ C. As hinted to in A2, a method may provide default values for arguments. The default values are evaluated in the context of the method, not the caller. -= Future Contracts +# Future Contracts A. The method provides names for each argument. 1. The caller may provide values for those arguments by name. doc/methods.txt 594649a54afe701577a701220e19959e1f0b55a5 Brian Ford bford@engineyard.com http://github.com/evanphx/rubinius/commit/ee532f2f01c70971fa8425874872709eefec4446 ee532f2f01c70971fa8425874872709eefec4446 2008-12-17T23:46:43-08:00 2008-12-17T23:46:43-08:00 Added blurbs to doc/contributing about specs. 642b2d511a00c58a61a58763f4d303cacde3c78b Brian Ford bford@engineyard.com