Every repository with this icon (
Every repository with this icon (
| Description: | Vim plugin for debugging Ruby applications (using ruby-debug-ide gem) edit |
-
1 comment Created 7 months ago by astashovTry to write implementation of socket's messages sender on CFeaturexIt should dramatically increase speed of the feedback.
Comments
-
0 comments Created 7 months ago by astashovUpdate variables after next suspending, but don't recreate themFeaturexNow variables are destroyed after next/step/cont command and recreated after suspending on next breakpoint. So, after next suspending all variables are closed again. Need to save ids of opened variables and open them after next suspending (if they exists still) .
Comments
-
8 comments Created 6 months ago by skammerDoesn't debug Sinatra app on OS XCritical bugxI do precisely following:
1) Open my sinatra app in MacVim. :pwd shows the right directory
2) Run :Rdebugger sinatra_app.rb. Output says "Debugger started"
3) Set a breakpoint
4) Open up a browser, go to the page with a breakpoint and... the server is not running, so nothing happens.Clearly debugger does not even start the app.
Comments
Make sure you have two processes running after :Rdebugger command:
- rdebug-ide
- ruby ruby_debugger.rb
Please, show output of all files in ~/.vim/tmp directory.
When I run :Rdebugger first time it starts two processes, but after a few seconds one of them shuts down. I can't tell wich one of them is ruby_debugger, but the one that keeps running has multiple ports open (39768, 39767, 56590).
When I run :Rdebugger second time both processes keep running. The new one has only one port open (39767).
ruby_debugger file contains this string http://gist.github.com/118463
There are two more files – ruby_debugger_log and ruby_debugger_output – but they are empty.Hmm... could you make sure what process exactly shuts down? It can help.
Meanwhile, I'll try to debug Sinatra on my local desktop.Looks like it doesn't work for me too. :(
Please, try to set breakpoint to some first string (e.g., to require 'sinatra') before :Rdebugger command. And then, execute :Rdebugger. It should stop on this breakpoint. (as for me, the debugger behaves this way).But after this, if I press 'continue', it will not run the server. Strange... Maybe problem in the ruby-debug-ide gem. I'll try to debug manually, by this gem.
I've tried to debug it manually. I run:
[anton@localhost sinatra]$ rdebug-ide -p 39767 -- sinatra_app.rb Fast Debugger (ruby-debug-ide 0.4.5) listens on localhost:39767And in other console, run irb and execute:
[anton@localhost sinatra]$ irb irb(main):001:0> require 'socket' => true irb(main):002:0> a = TCPSocket.open('localhost', 39767) => # irb(main):003:0> a.puts('start')After this, rdebug-ide just completed its work. Sinatra didn't run the server.
So at least we know the reason why it doesn't stop at breakpoints. It simply never runs.
-
1 comment Created 6 months ago by scottjacobsenDebugger doesn't seem to work when workling is being used.BugxNot sure if this is a bug or an FYI. My app makes use of workling and starling to do async processing. It seem some part of this debugger stack is doesn't work if a workling process is being used.
I started the debugger with :Rdebugger and set a breakpoint in a controller with \b, The line was highlighted in red. The ruby_debugger_log indicated the break point was set. I refreshed the web page, but the app didn't break at the breakpoint.
In my ruby_debugger_log:
cat ruby_debugger_log2009/06/10 11:20:47 Start debugger 2009/06/10 11:21:38 Set breakpoint to: /home/scott/git/RepgenDataLoader/app/controllers/database_controller.rb:108 2009/06/10 11:21:56 Set breakpoint to: /home/scott/git/RepgenDataLoader/app/controllers/database_controller.rb:5There must be some kind of workling incompatibility. I noticed this odd thing:
After I start the debugger netstat shows the debugger listening) (note that I modifed the debugger to listen on 39997 and 39998):
tcp 0 0 127.0.0.1:39997 0.0.0.0:* LISTEN 25586/ruby1.8 tcp 0 0 127.0.0.1:39998 0.0.0.0:* LISTEN 25589/rubyAfter I stop the debugger using :RdbStop netstat shows this:
tcp 0 0 127.0.0.1:39997 0.0.0.0:* LISTEN 25634/worklingWorkling seems to have take over the debugger port. Very strange.
I cannot start the debugger because workling is listening on the debugger port. No matter what port I start the debugger on this seems to happen. I need to kill the workling process.
When I don't start my workling/starling processes the debugger works fine.
Comments
Really, pretty strange. Unfortunately, I don't have experience with workling/starling, never used them with/without debugger. I even don't know how I can help you, sorry...
If you find reason of this strange behaviour, I'll be happy if you send me patch, or just explanation of this bug :). Anyway, thanks for this issue, I'll leave it here unclosed.
-
After running :Rdebugger my gvim window starts blinking.
Text editing area doesn't respond to any command. But upper GUI menu works fine.The command line says: Loading Debugger...
Comments
Hi!
Please send contents of log files (in vimfiles/tmp directory).I am not a skilled vim developer, but I tried to debug it and figure out that the script is doing something recursively then trying to execute:
let self.debugger_pid = self._get_pid(self.debugger_port, 1)Ah! It means ruby_debugger.rb is not started by some reason. Could you try to run it manually? For this, put after
" Start in background if has("win32") || has("win64") silent exe '! start ' . rdebug let debugger = 'ruby "' . expand(self.runtime_dir . "/bin/ruby_debugger.rb") . '"' . debugger_parametersthis string:
echo(debugger)Then, please show this command (result of echo) and try to run it manually. And then, tell me what you've got. :)












I've written it for Linux.