rubymine Debugger.start nie nazywa jeszcze

Question

wychodził ten wyjątek podczas debugowania z rubymine ...

Debugger.start is not called yet. 

Answer 1

Po pewnym czasie próbuje innych proponowanych rozwiązań, stwierdziliśmy, że miałem następujące w pliku gem:

gem "debugger" 

to powoduje konflikt jakoś do debuggera ... Usuwanie ta linia rozwiązać go do mnie ...

Dzięki ...

---

Źródło: Debugger crashes when it hits the first breakpoint

Answer 2

Dla innych, którzy prowadzą do tego i nie można usunąć debugger z Gemfile, warto po linku źródłowym Mustafah usług.

Dalsze aktualizacje do dyskusji wskazują, że możesz dodać unless ENV['RM_INFO'] do Gemfile (i po każdym żądaniu gemera debuggera), aby użyć debuggera RM i zezwolić innym na projekt na debugger wiersza poleceń.

Answer 3

Jako dodatek do komentarza Mustafah jest, zajęło mi trochę czasu, aby wyśledzić ten wariant emisji:

gem 'pry-full' 
gem 'debugger' 

Obie te linie były przyczyną problemu, więc musiałem zmienić na:

unless ENV['RM_INFO'] 
    gem 'pry-full' 
    gem 'debugger' 
end 

Skąd wiadomo, które klejnoty mogą pośrednio ładować klejnot debuggera? Spójrz w Gemfile.lock dla wpisów, które sugerują, że to depedency:

pry-debugger (0.2.2) 
    debugger (~> 1.3) 
    pry (~> 0.9.10) 

Answer 4

Inne rozwiązania nie będzie działać, jeśli można sprawdzić w swojej Gemfile.lock - będzie się różnić w zależności od tego, co maszyna została wygenerowana w (nie zrobił” t spróbuj, ale na pewno to prawda).

Zamiast umieścić klejnot w osobnej sekcji, brak domyślnej w Gemfile:

group :debugging do 
    gem 'debugger' 
end 

Następnie w environment.rb, wymagam go warunkowo. Również nie mam RM_INFO, więc sprawdzić RUBYLIB env var:

Bundler.require(:default, Rails.env) if defined?(Bundler) 

unless ENV['RUBYLIB'] =~ /RubyMine/ 
    require 'debugger' 
end 

Answer 5

miałem tylko jedną zależność, że łamał debugger RubiMine za: pry-debugger. Zastąpienie go numerem pry-nav, który nie jest zależny od debugger, rozwiązało problem.