Ce n'est pas un jargon spécifique à Ruby; c'est commun à la plupart des déboguages.
En ce qui concerne la pile trames
Vous avez probablement vu des traces de pile:
/usr/local/rvm/gems/ree-1.8.7-2010.02/gems/redgreen-1.2.2/lib/redgreen.rb:28:in `write': Broken pipe (Errno::EPIPE)
from /usr/local/rvm/gems/ree-1.8.7-2010.02/gems/redgreen-1.2.2/lib/redgreen.rb:28:in `output_single'
from /usr/local/rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:72:in `add_fault'
from /usr/local/rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:70:in `to_proc'
from /usr/local/rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/test/unit/util/observable.rb:78:in `call'
La trace complète vous montre la "pile d'appel". La ligne en haut est l'endroit où l'exception a été lancée, et les lignes en dessous indiquent le chemin que votre programme a emprunté pour atteindre ce point. Chacune de ces lignes est un niveau dans la pile, appelé "frame de pile". Ainsi, lorsqu'une exception est levée, le cadre de la pile en cours est le sommet de la pile. Si vous passez à frame -1, vous vous déplacez en bas de la pile d'appels. Pensez à la pile d'appels comme une pile d'assiettes. Lorsque vous appelez une fonction, vous ajoutez une plaque à la pile, et lorsque vous sortez de cette fonction, vous enlevez une plaque de la pile. Chaque plaque est un cadre. Comme vous finissez généralement par appeler des fonctions dans des fonctions, vous vous retrouvez avec des piles d'appels assez profondes, et les monter et descendre peut être utile pour le débogage, pour évaluer les variables locales et l'état à chaque point de la pile d'appels.
Si vous souhaitez en savoir plus sur les piles d'appels, Wikipedia has a nice article.
En ce qui concerne les discussions
La plupart des tous les langages de programmation modernes sont multi-thread, ce qui signifie qu'ils peuvent exécuter plusieurs chemins de code (presque) en même temps. Imaginez par exemple que vous ayez une application visuelle et que vous effectuiez des calculs coûteux. Votre interface graphique ne sera pas en mesure de réagir à une entrée de l'utilisateur pendant que ce calcul est en cours d'exécution, ce qui rend l'application semble être gelé à l'utilisateur. Vous résoudriez cela en exécutant deux threads: Un thread serait responsable de l'acceptation et de la gestion des entrées utilisateur et de la peinture de l'interface graphique, et l'autre thread serait responsable de faire votre lourd calcul. Votre thread de calcul pourrait être coincé dans une boucle coûteuse et votre thread graphique continuerait à courir et à peindre l'interface graphique. Si vous exécutez une application multithread, vous devez sélectionner le thread dans lequel vous voulez évaluer vos commandes de débogage (expressions), car chaque thread sera dans différents points de votre code, et aura différentes piles d'appel et différentes variables locales et état et autres. C'est le contexte de l'évaluation.
Cependant, j'ai remarqué qu'il s'agit d'une question Rails, et Rails est (par défaut) monothread, donc vous ne devriez pas avoir à vous soucier des threads. Chris Heald a donné une réponse vraiment fantastique.