Comment faire pour exécuter la CISR.démarrer dans le contexte de l'actuelle classe

J'ai été tout simplement en passant par PragProg des Essais en Continu Avec Ruby, où ils parlent de l'invocation IRB dans le contexte de la classe en cours d'inspecter le code manuellement.

Cependant, ils citent que si vous appelez IRB.start dans une classe, auto est prédéfini, et fait référence à l'objet que nous étions lorsque le départ a été appelé qui n'est pas vrai dans mon cas.

Même pour exemple très simple comme

a = "hello"
require 'irb'
ARGV.clear # otherwise all script parameters get passed to IRB
IRB.start

Lorsque j'essaie d'accéder à la a variable, j'ai l'évidente 

NameError: undefined local variable or method `a' for main:Object

Il ne fonctionne que quand je change de a à la variable globale

$a = "hello"
require 'irb'
ARGV.clear # otherwise all script parameters get passed to IRB
IRB.start

alors je peux y accéder

irb(main):001:0> $a
=> 1

Est-il un moyen de contourner cela pour l'accès local et les variables d'instance de la classe en cours?

InformationsquelleAutor Jakub Arnold | 2010-11-15
  1. 14

    Je vous suggère d'essayer ce en ripl, un cisr alternative. L'exemple ci-dessus fonctionne:

    a = 'hello'
require 'ripl'
Ripl.start :binding => binding

    Noter que les variables locales de travailler en raison de votre passage de l'actuelle liaison avec l' :l'option de reliure.

    Vous pourriez peut-être faire la même chose dans la cisr, mais comme il est mal documenté et non-testés, vos chances de le faire proprement sont minces à aucun.

    • Malheureusement, c'est un no-go en vertu de JRuby.
    • Vous devez ouvrir une question: github.com/cldwalker/ripl/issues. ripl a été vérifié pour fonctionner sur jruby
    • La deuxième des conseils pour éviter de RIR pour cela. Pry est une autre option.
    InformationsquelleAutor cldwalker
  2. 37

    Comme vous l'avez déjà découvert, self ne fait pas référence à l'objet où la CISR a été commencé, mais à la TOPLEVEL_BINDING, ce qui semble être une instance de la Object classe elle-même.

    Vous pouvez toujours exécuter un CISR séance avec une classe spécifique ou un objet comme le contexte, mais ce n'est pas aussi simple que juste de départ de la CISR.

    Si vous vous souciez de démarrage de la CISR avec un contexte spécifique, alors il est vraiment facile à faire quand vous êtes à partir de la CISR manuellement. Juste au début de la CISR normalement, puis d'appeler la irb méthode, en lui passant l'objet/classe que vous voulez, selon le contexte.

    $ irb
irb(main):002:0> require 'myclass'
=> true
irb(main):003:0> irb MyClass
irb#1(MyClass):001:0> self
=> MyClass

    Vous pouvez également démarrer une session de la CISR par programme et spécifier le contexte, mais il n'est pas aussi facile qu'il devrait être parce que vous avez de reproduire une partie de la CISR la start-up de code. Après beaucoup d'expérimentation et de creuser autour de la CISR, le code source, j'ai été en mesure de venir avec quelque chose qui fonctionne:

    require 'irb'
IRB.setup nil
IRB.conf[:MAIN_CONTEXT] = IRB::Irb.new.context
require 'irb/ext/multi-irb'
IRB.irb nil, self
    • À mon humble avis, la seule réponse qui répond à cette question.
    • Upvoted, fonctionne pour moi, et répond à la question d'origine (au lieu de suggérer d'autres solutions), merci!
    • Épique réponse. Merci, fonctionne tout à fait pour moi (ruby 1.9.3) premier essai. Merci de faire ce travail, donc je ne pas avoir à le faire.
    • Dang, pas de travail ici. Peut-être que c'est parce que nous sommes à l'aide de JRuby. 🙁
    InformationsquelleAutor bryant
  3. 10

    Au lieu de mondial vous pouvez utiliser les variables d'instance, par exemple:

    require 'irb'
@a = "hello"
ARGV.clear
IRB.start

>> @a
=> "hello"
    • Ce serait en utilisant les variables d'instance de changement ?
    • Eh bien, contrairement aux variables locales elles restent visibles après IRB.start (c'est à dire, en remplacement de @a dans ce code avec a ne fonctionnerait pas), mais à la différence des variables globales ils ne polluent pas l'espace de noms global (juste celui de l'objet principal). Dans tous les cas, d'autres réponses déjà mention des façons d'obtenir des locaux de travail, ainsi, si à l'aide d'une bibliothèque ou d'un peu plus de travail n'est pas un problème, puis ceux-ci sont de meilleures alternatives. (Je préfère Soulever moi-même.)
    InformationsquelleAutor Arkku
  4. 10

    Utilisation Pry:

    a = 'hello'
require 'pry'
binding.pry
    • J'ai quelques problèmes avec Ripl (qui est la solution retenue) de me donner un autre contexte que ce que j'attendais. Donc, à bien y regarder, je vais voter pour Soulever ainsi.
    • Je n'arrivais pas à le soulever à travailler, peut-être une incompatibilité /usr/local/share/gems/gems/term-ansicolor-1.2.2/lib/term/ansicolor.rb:188:in 'color': wrong number of arguments (0 for 1..2) (ArgumentError) from /usr/local/share/gems/gems/pry-0.10.0/lib/pry/output.rb:35:in 'decolorize_maybe'
    InformationsquelleAutor horseyguy
  5. 6

    Voici comment appeler de la CISR à partir de votre script dans le contexte de l'endroit où vous l'appel de la CISR.commencer..

    require 'irb'
class C
    def my_method
        @var = 'hi'
        $my_binding = binding
        IRB.start(__FILE__)
    end
end

C.new.my_method

    De l'exécution de votre script va invoquer la CISR. Lorsque vous arrivez à la demande que vous avez une chose à faire...

    % ./my_script.rb
irb(main):001:0> @var.nil?
=> true
irb(main):002:0> cb $my_binding
=> #<C:0x000000009da300 @var="hi">
irb(#<C:0x000000009da300>):003:0> @var.nil?
=> false
irb(#<C:0x000000009da300>):004:0> @var
=> "hi"

    Profitez-en!

    • Cela peut être. Mais la question est de savoir "Comment faire pour exécuter la CISR.démarrer dans le contexte actuel de la classe". Ma réponse est le seul qui répond vraiment à la question.
    • Vous ne pouvez pas accéder aux variables locales, donc cela ne répond pas à la question.
    InformationsquelleAutor Ben
  6. 5

    Comme des Rubis 2.4.0, vous pouvez le faire:

    require 'irb'
binding.irb

    Cela va démarrer une IBR REPL où vous aurez la valeur correcte pour self et vous pourrez accéder à toutes les variables locales et les variables d'instance qui sont dans la portée. Tapez Ctrl+D ou quit pour reprendre le cours de votre Ruby programme.

    InformationsquelleAutor David Grayson
  7. 2

    Ma solution pour Ruby 2.2.3. Il est très similaire à Bryant

    def to_s
  "Sample"
end

def interactive
  banana = "Hello"
  @banana = "There"
  require 'irb'
  IRB.setup(nil)
  workspace = IRB::WorkSpace.new(binding)
  irb = IRB::Irb.new(workspace)
  IRB.conf[:MAIN_CONTEXT] = irb.context
  irb.eval_input
end

irb(Sample):001:0> puts banana
Hello
=> nil
irb(Sample):002:0> puts @banana
There
=> nil
irb(Sample):003:0>

    Je peux accéder à des variables locales et des variables d'instance. Le require 'irb' de cours pourrait être en haut du fichier. Le réglage de banana et @banana est juste pour prouver que je peux y accéder à partir de la cisr invite. Le to_s est une méthode qui permet d'obtenir une assez prompte, mais il ya d'autres choix. Et il n'y a pas vraiment de raison de faire une méthode distincte, mais comme il est, vous pouvez plop ce dans n'importe où et cela devrait fonctionner.

    InformationsquelleAutor pedz
  8. 0

    La ruby-debug-base gem ajoute un binding_n méthode à la Noyau module et cela vous donnera accès à la liaison de l'objet qui peut être utilisé dans un eval pour donner accès à la pile des appels de variables. N'oubliez pas de problème Débogueur.début pour activer la pile des appels de suivi.

    Voici un exemple montrant son utilisation pour connaître ce qui se passe à l'intérieur de de la cisr (un Rubis programme). On pourrait se poser la besoin's et Débogueur.début à l'intérieur de votre propre code Ruby ainsi.

    $ irb
ruby-1.8.7-p302 > require 'rubygems'
 => true 
ruby-1.8.7-p302 > require 'ruby-debug-base'
 => true 
ruby-1.8.7-p302 > Debugger.start
 => true 
ruby-1.8.7-p302 > puts caller
/tmp/.rvm/rubies/ruby-1.8.7-p302/lib/ruby/1.8/irb/workspace.rb:52  :i  n `irb_binding' #`
/tmp/.rvm/rubies/ruby-1.8.7-p302/lib/ruby/1.8/irb/workspace.rb:52
=> nil 
ruby-1.8.7-p302 > eval "main", binding_n(2)
 => #<Object:0xb7762958 @prompt={:PROMPT_I=>"ruby-1.8.7-p302 > ", :PROMPT_N=>"  ruby-1.8.7-p302 ?> ", :PROMPT_S=>"ruby-1.8.7-p302%l> ", :PROMPT_C=>"ruby-1.8.7-p302 > ", :AUTO_INDENT=>true, :RETURN=>" => %s \n"}> 
ruby-1.8.7-p302 >

    Si vous êtes prêt à exécuter une version patchée de Rubis pour 1.9.2 voir http://gitnub.com/rocky/rb-threadframe pour ce que je pense est le meilleur accès à la pile d'appel. Rubinius fournit cette fonctionnalité intégrée dans la via Rubinius::VM.backtrace.

    InformationsquelleAutor