Ruby In Steel Developer 1.3 issues

[Mark Bixby]

After uninstalling my registered copy of RIS DE 1.2 and then installing the new 1.3 release, various issues soon surfaced:

1) On two separate occasions the one-click Rails debugger hung on me.  VS 2005 was non-responsive, so I had to close the main VS window and click the "end now" button on the resulting Windows non-responsive application dialog box.  I would then restart VS, but whenever I would try to launch the one-click Rails debugger, no messages (success or failure) would appear in the console window.  I could exit and restart VS several times and the problem would not clear.  Both times I had to reboot my machine to regain the ability to launch the one-click Rails debugger.  The 1.2 debugger would occasionally flake out for me at times, but stopping and restarting the debugger within VS would clear the problem.  I did not ever have to reboot my machine under 1.2 to clear a Ruby In Steel problem.

The two scenarios that caused the one-click debugger to hang were 1) setting all of the "Autos Window" configuration options to True (I know, ill-advised for performance reasons) and 2) trying to use a conditional breakpoint.

2) Speaking of conditional breakpoints, when I tested one under 1.3 that always evaluated to true, the debugger would break (in the breakpoint sense) successfully.  However, when I modified the condition to always evaluate to false, a variety of strange exceptions would be raised, from either gems or parts of my code far removed from the original breakpoint.  Clearly the false conditional breakpoint was not being entirely transparent.  Something is definitely buggy here.

3) My VS solution has two projects -- one project for my web app codebase at C:\Ruby\pds (created with Ruby In Steel 1.2), and another project for the Instant Rails gems at C:\Ruby\IR2\ruby\lib\ruby\gems\1.8\gems that was converted in-place by the Ruby In Steel 1.2 conversion wizard.  When I would start the debugger for my web app, Ruby In Steel would set RAILS_ROOT incorrectly to the gems project path of C:\Ruby\IR2\ruby\lib\ruby\gems\1.8\gems instead of the web app path of C:\Ruby\pds.  This same thing would happen under 1.2, but I was able to solve it by setting the Ruby In Steel "Working Directory" configuration option for the gems project to be C:\Ruby\pds.

I have set the working directory under 1.3, but it still is prone to setting RAILS_ROOT to the gems path, even though I have the web app project selected in Solution Explorer.

But curiously it will set RAILS_ROOT to the correct C:\Ruby\pds path if I start the one-click debugger when the Ruby In Steel configuration dialog box for my web app project is open.  If the configuration dialog box for the gems project is open, RAILS_ROOT gets set to the gems path of C:\Ruby\IR2\ruby\lib\ruby\gems\1.8\gems.

This seems bug-like to me.  It shouldn't be necessary to be sitting in an open configuration dialog box to get RAILS_ROOT set correctly.

[Dermot]

thanks for the report ...

You shouldn't need to reboot your machine. Probably the Ruby process or VS itself is getting snarled up on trying to output or analyse a very large quantity of information. You should be able to bring up the Task Manager by pressing CTRL-ALT-DEL and then look for any ruby.exe processes and kill them off - that should free up the system. If that doesn't work, then it's VS that's in trouble, but again, you can kill the VS process off without rebooting (look for devenv.exe). The Autos display can be pretty lethal in Rails (that's why the switch was put in). You can literally get megabytes of Ruby data back, because a single variable can point to other variables and so on upto a hundred levels deep. Even worse, this whole process occurs again *every* time you step. I suspect that the system would eventually recover. Of course, it could be in a loop and never recover ... can you do a bit more experimenting here? I think that I might have another go at this in the next version to make sure that the system stays responsive under all circumstances.

On conditional breakpoints - these are done using Ruby code (the expression is sent to the Ruby interpreter and evaluated by Ruby) so you can accidentally screw something up. So if you say 'x = 3' and you meant 'x == 3' then x will be set to '3' - probably not what you want. Could this be what is happening here?

The working directory thing sounds odd - I'll have a look at this and get back to you. But the whole properties thing has changed. There are now Configuration Dependant Properties as well as the original ones and things have moved around. You may not be setting the correct configuration and RiS is picking up the wrong one. We've covered this in detail in the manual and help, so it may be worth going over this if you aren't familiar with the way VS does configuration dependent proiperties.

Dermot

[cfis]

Testing 1.3 and having issues with the debugger.

First - the autos and watch windows are broken.  I have a watch set on the request object (line 129 in actionpack-2.1.0\lib\action_controller\session_management.rb).  This is the value returned:

request   failed: expecting "EOF", found '|' : request|

Then after that appears the correct debug information, but as a long string.

Next, I've set just in-time debugging to  be true, but it is not breaking for an argument error (2 parameters instead of 1).

This is VS 2008, Rails 2.1, Ruby 1.8.6 patchlevel 111 running on Windows Vista SP1.

Thanks

not work.  When I try to evaluate an expression (this is a Rails project I imported), I get:

[Dermot]

Can you post the string here (or e-mail me via the usual support address). It's quite probable that DHH has changed an inspector in Rails 2.1 and it would help to know which one it is.

I'll check out the argument error  problem and get back to you.

Dermot

[Dermot]

I've just tried the JIT debugging and it seems to work fine for me. This is the code I used:

Code:

def x (a, b)
puts "here"
end

x(1, 2, 3)

I did notice a peculiarity when I first started up, in that JIT was off and it fired anyway (which it shouldn't). I then opened up the Property page and get JIT to true, clicked Save All and the tried it again - it fired as it should. I then set JIT to be off, clicked Save All and ran it again - debugger didn't fire, which is correct. So, can you try that sequence with this code and let me know the result? I think there might be a small initialization problem somewhere.

Dermot

[Dermot]

Re: Rails and the working directory.

Yes - there's a bug there. It always takes the project directory (which you can't change) instead of the setting for the Working Directory, which is not, I would guess, what you want.

We're planning a bug fix release in a couple of weeks (once we've collected a few more), so I'll fix it then.

Dermot

[Mark Bixby]

Re working directory -- thanks for the confirmation and a future fix.  Through additional testing today I discovered that my original guess of a working directory workaround was mistaken, and that RIS is always setting RAILS_ROOT based on the project directory.  Until your fix arrives I will use my true workaround method of opening up the project properties for the primary project in order implicitly set the RAILS_ROOT that I require.

Re false conditional breakpoints causing side-effects -- my test was to set a breakpoint in an activerecord gem method within postgresql_adapter.rb and specify a conditional breakpoint expression of:

port == 666

Where port is a local method Fixnum variable and will never contain the value 666.

When I run my app, the breakpoint never fires, but I got the exception as shown at:

http://www.bixby.org/mark/breakpoint-exception1.PNG

The above exception only occurs when the false conditional breakpoint is set.

I clicked the Continue button, but then Visual Studio went non-responsive and Windows Task Manager did not show any VS, Ruby, or application-related processes using any CPU time.  I had to force-close VS via "End Now" and then I rebooted my machine just to be safe.

[Dermot]

yes - there is a bug there. (quite a subtle one - it took a bit of staring at the code, but I think I've fixed it).

I've uploaded a fixed Ruby debugger file (steelcylon.rb) to the downloads area steelcylon.rb.

Download this and copy it to the debugger directory (SapphireSteel Software/Ruby In Steel/V1.0/Debugger). It might be a good idea to keep a backup of the original file in case my fix has screwed up anything.

Actually, there is still a small bug: if the conditional breakpoint is hit, you have to press F5 twice to get past it. I'll fix that in the bug fix release.

Dermot

[Mark Bixby]

I confirm that the new steelcylon.rb solves the false breakpoint exception problem.

Last week I noticed the double conditional breakpointing, and that is indeed unchanged by the new steelcylon.rb.

[cfis]

Hi Dermot,

I installed the updated steelcylon.rb file.  Now when I put a breakpoint on that line (line 129, session_management.rb, Rails 2.1), it won't trigger.  I can put a breakpoint on the calling method, and the method it calls though.  Weird.

Anyway, when I step into that method (process_with_session_management), the local variables are request, response and method).  However, the locals method has only one line with a red exclamation mark that looks disabled and a huge string, which I attach below.

Thanks - Charlie

         failed: expecting "EOF", found '|' : request|#<ActionController::CgiRequest:0x6be9460 @env={"SERVER_NAME"=>"localhost", "PATH_INFO"=>"/user/login", "HTTP_ACCEPT_ENCODING"=>"gzip,deflate", "HTTP_USER_AGENT"=>"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16 (.NET CLR 3.5.30729)", "SCRIPT_NAME"=>"/", "SERVER_PROTOCOL"=>"HTTP/1.1", "HTTP_CACHE_CONTROL"=>"max-age=0", "HTTP_IF_NONE_MATCH"=>"\"c77a0416298ed31b2f137643ed7e28d5\"", "HTTP_ACCEPT_LANGUAGE"=>"en-us,en;q=0.5", "HTTP_HOST"=>"localhost:3000", "REMOTE_ADDR"=>"127.0.0.1", "SERVER_SOFTWARE"=>"Mongrel 1.1.5", "HTTP_KEEP_ALIVE"=>"300", "REQUEST_PATH"=>"/user/login", "HTTP_COOKIE"=>"mb_session_key=f92badc3d33eba46109f0e18ea12525c; context=center=-104.96612548828124%2C39.705601889439095&scale=0.000005999026093205354&crs=4326&width=520&height=360&map_id=1", "HTTP_ACCEPT_CHARSET"=>"ISO-8859-1,utf-8;q=0.7,*;q=0.7", "HTTP_VERSION"=>"HTTP/1.1", "REQUEST_URI"=>"/user/login", "SERVER_PORT"=>"3000", "GATEWAY_INTERFACE"=>"CGI/1.2", "HTTP_ACCEPT"=>"text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5", "HTTP_CONNECTION"=>"keep-alive", "REQUEST_METHOD"=>"GET"}, @cgi=#<Mongrel::CGIWrapper:0x6bec3b8 @stdinput=#<IO:0x3d76b00>, @out_called=false, @response=#<Mongrel::HttpResponse:0x6befea0 @socket=#<TCPSocket:0x6bf213c>, @header_sent=false, @status=404, @reason=nil, @body_sent=false, @body=#<StringIO:0x6befdd8>, @header=#<Mongrel::HeaderOut:0x6befd24 @allowed_duplicates={"WWW-Authenticate"=>true, "Set-Cookie2"=>true, "Set-Cookie"=>true, "Warning"=>true}, @sent={"Date"=>true}, @out=#<StringIO:0x6befd88>>, @status_sent=false>, @params={}, @cookies={"mb_session_key"=>["f92badc3d33eba46109f0e18ea12525c"], "context"=>["center=-104.96612548828124,39.705601889439095&scale=0.000005999026093205354&crs=4326&width=520&height=360&map_id=1"]}, @input=#<StringIO:0x6bf02d8>, @head={}, @multipart=false, @handler=#<Mongrel::Rails::RailsHandler:0x6833a8c @listener=#<Mongrel::HttpServer:0x4ea1448 @socket=#<TCPServer:0x4ea140c>, @throttle=0.0, @port=3000, @timeout=60, @host="0.0.0.0", @classifier=#<Mongrel::URIClassifier:0x4ea13bc @root_handler=[#<Mongrel::Rails::RailsHandler:0x6833a8c ...>], @matcher=//, @handler_map={"/"=>[#<Mongrel::Rails::RailsHandler:0x6833a8c ...>]}>, @acceptor=#<Thread:0x6aa3114 sleep>, @num_processors=1024, @workers=#<ThreadGroup:0x4ea136c>>, @guard=#<Mutex:0x6833744>, @active_request_path="/user/login", @files=#<Mongrel::DirHandler:0x6833a64 @default_content_type="application/octet-stream", @index_html="index.html", @path="D:/mapbuzz/web/trunk/public", @listing_allowed=false>>, @output_hidden=nil, @args=nil, @output_cookies=nil, @default_really_final=false, @request=#<Mongrel::HttpRequest:0x6bf03b4 @socket=#<TCPSocket:0x6bf213c>, @params={"SERVER_NAME"=>"localhost", "PATH_INFO"=>"/user/login", "HTTP_ACCEPT_ENCODING"=>"gzip,deflate", "HTTP_USER_AGENT"=>"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16 (.NET CLR 3.5.30729)", "SCRIPT_NAME"=>"/", "SERVER_PROTOCOL"=>"HTTP/1.1", "HTTP_CACHE_CONTROL"=>"max-age=0", "HTTP_IF_NONE_MATCH"=>"\"c77a0416298ed31b2f137643ed7e28d5\"", "HTTP_ACCEPT_LANGUAGE"=>"en-us,en;q=0.5", "HTTP_HOST"=>"localhost:3000", "REMOTE_ADDR"=>"127.0.0.1", "SERVER_SOFTWARE"=>"Mongrel 1.1.5", "HTTP_KEEP_ALIVE"=>"300", "REQUEST_PATH"=>"/user/login", "HTTP_COOKIE"=>"mb_session_key=f92badc3d33eba46109f0e18ea12525c; context=center=-104.96612548828124%2C39.705601889439095&scale=0.000005999026093205354&crs=4326&width=520&height=360&map_id=1", "HTTP_ACCEPT_CHARSET"=>"ISO-8859-1,utf-8;q=0.7,*;q=0.7", "HTTP_VERSION"=>"HTTP/1.1", "REQUEST_URI"=>"/user/login", "SERVER_PORT"=>"3000", "GATEWAY_INTERFACE"=>"CGI/1.2", "HTTP_ACCEPT"=>"text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5", "HTTP_CONNECTION"=>"keep-alive", "REQUEST_METHOD"=>"GET"}, @dispatchers=[], @body=#<StringIO:0x6bf02d8>>>, @request_parameters={}, @request_method=:get, @symbolized_path_parameters=nil, @query_parameters={}, @path_parameters={"resource"=>"login", "action"=>"index", "controller"=>"user"}, @session_options={:cookie_only=>false, :prefix=>"ruby_sess.", :database_manager=>CGI::Session::MemCacheStore, :tmpdir=>"D:/mapbuzz/web/trunk/tmp/sessions/", :session_key=>"_session_id", :session_path=>"/", :cache=><MemCache: 1 servers, 1 buckets, ns: "mapbuzz-development", ro: false>}, @parameters=nil, @content_length=0>|ActionController::CgiRequest|0|response|#<ActionController::CgiResponse:0x6be92d0 @assigns=[], @cgi=#<Mongrel::CGIWrapper:0x6bec3b8 @stdinput=#<IO:0x3d76b00>, @out_called=false, @response=#<Mongrel::HttpResponse:0x6befea0 @socket=#<TCPSocket:0x6bf213c>, @header_sent=false, @status=404, @reason=nil, @body_sent=false, @body=#<StringIO:0x6befdd8>, @header=#<Mongrel::HeaderOut:0x6befd24 @allowed_duplicates={"WWW-Authenticate"=>true, "Set-Cookie2"=>true, "Set-Cookie"=>true, "Warning"=>true}, @sent={"Date"=>true}, @out=#<StringIO:0x6befd88>>, @status_sent=false>, @params={}, @cookies={"mb_session_key"=>["f92badc3d33eba46109f0e18ea12525c"], "context"=>["center=-104.96612548828124,39.705601889439095&scale=0.000005999026093205354&crs=4326&width=520&height=360&map_id=1"]}, @input=#<StringIO:0x6bf02d8>, @head={}, @multipart=false, @handler=#<Mongrel::Rails::RailsHandler:0x6833a8c @listener=#<Mongrel::HttpServer:0x4ea1448 @socket=#<TCPServer:0x4ea140c>, @throttle=0.0, @port=3000, @timeout=60, @host="0.0.0.0", @classifier=#<Mongrel::URIClassifier:0x4ea13bc @root_handler=[#<Mongrel::Rails::RailsHandler:0x6833a8c ...>], @matcher=//, @handler_map={"/"=>[#<Mongrel::Rails::RailsHandler:0x6833a8c ...>]}>, @acceptor=#<Thread:0x6aa3114 sleep>, @num_processors=1024, @workers=#<ThreadGroup:0x4ea136c>>, @guard=#<Mutex:0x6833744>, @active_request_path="/user/login", @files=#<Mongrel::DirHandler:0x6833a64 @default_content_type="application/octet-stream", @index_html="index.html", @path="D:/mapbuzz/web/trunk/public", @listing_allowed=false>>, @output_hidden=nil, @args=nil, @output_cookies=nil, @default_really_final=false, @request=#<Mongrel::HttpRequest:0x6bf03b4 @socket=#<TCPSocket:0x6bf213c>, @params={"SERVER_NAME"=>"localhost", "PATH_INFO"=>"/user/login", "HTTP_ACCEPT_ENCODING"=>"gzip,deflate", "HTTP_USER_AGENT"=>"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16 (.NET CLR 3.5.30729)", "SCRIPT_NAME"=>"/", "SERVER_PROTOCOL"=>"HTTP/1.1", "HTTP_CACHE_CONTROL"=>"max-age=0", "HTTP_IF_NONE_MATCH"=>"\"c77a0416298ed31b2f137643ed7e28d5\"", "HTTP_ACCEPT_LANGUAGE"=>"en-us,en;q=0.5", "HTTP_HOST"=>"localhost:3000", "REMOTE_ADDR"=>"127.0.0.1", "SERVER_SOFTWARE"=>"Mongrel 1.1.5", "HTTP_KEEP_ALIVE"=>"300", "REQUEST_PATH"=>"/user/login", "HTTP_COOKIE"=>"mb_session_key=f92badc3d33eba46109f0e18ea12525c; context=center=-104.96612548828124%2C39.705601889439095&scale=0.000005999026093205354&crs=4326&width=520&height=360&map_id=1", "HTTP_ACCEPT_CHARSET"=>"ISO-8859-1,utf-8;q=0.7,*;q=0.7", "HTTP_VERSION"=>"HTTP/1.1", "REQUEST_URI"=>"/user/login", "SERVER_PORT"=>"3000", "GATEWAY_INTERFACE"=>"CGI/1.2", "HTTP_ACCEPT"=>"text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5", "HTTP_CONNECTION"=>"keep-alive", "REQUEST_METHOD"=>"GET"}, @dispatchers=[], @body=#<StringIO:0x6bf02d8>>>, @headers={"cookie"=>[], "Cache-Control"=>"no-cache"}, @body="", @session=[]>|ActionController::CgiResponse|0|   

[cfis]

Another issue I've seen is that Ruby in Steel is fairly slow.  I'm using a Core 2 Duo Thinkpad t61 laptop, 2Gb of RAM, Vista Business, Rails 2.1, Ruby 1.8.6.  For comparison, I also run Netbeans on this machine, which is much faster.

In particular:

1.  Opening the solution takes 45 seconds (this is with Visual Studio already open).  Netbeans takes 15 seconds, and that includes the full time of launching NetBeans.  Note the full solution includes 15,000 files.

2.  There is about a five second delay for each line when stepping through code in the debugger - netbeans is almost instantaneous.

I know that isn't too much information to go on, but I'd be happy to provide whatever additional information you need.

[Dermot]

Thanks for the debugger info ... the problem is at column 4407 and it's due to this Rails code in

C:\ruby\lib\ruby\gems\1.8\gems\activesupport-2.1.0\lib\active_support\vendor\memcache-client-1.5.0\memcache.rb

 at line 159 (on my machine):

Code:

def inspect
    "<MemCache: %d servers, %d buckets, ns: %p, ro: %p>" %
      [@servers.length, @buckets.length, @namespace, @readonly]
  end

If you comment this out (temporarily) and replace it with this:

Code:

def inspect
    "commented out"
  end

it should work.

The problem comes about beacuse the inspect format is just a convention which most people respect but which Rails sometimes doesn't. You can put whatever you want into an inspect function (and Rails is by no means the worst offender - some of the contributed Ruby code in the libraries is grim, to say the least). My problem is that these inspect functions are called by Ruby to pass me the data so that I can make a nice tree out of it in the debugger windows, and if they dont follow the convention, the parsing fails and you get the error you see.

I'll add this to my ever growing list of 'exceptions' and I'll fix it in the next bug fix release.


On the slowness of the debugger, I think this is due to the inspectors being called for every step (which is slow). It's usually the Autos window which is the problem here. Try closing the Autos window and then stepping. If that doesn't fix it, close any windows that display any Ruby variables.

I'll have a think about doing this in a better way, so that you have to manually refresh the variables say - I think this is done for somethings in C#.

I'll have a look at the opening projects. I did speed this up considerably, but maybe something has got lost in the latest release.

Dermot

[Dermot]

I've done some timing on opening large projects:

5000 files    ->  7.2 sec
10000 files  -> 14.2 sec
15000 files  -> 21.7 sec

this is non-optimized code running under the debugger, so I would expect the times in the released product to be somewhat faster.

This is on a a Core Duo 2.4GHz with 3GB, so I can't see where the extra time is coming from. Any chance you could zip up your project and send it to me at the support e-mail? (I'm assuming that the files are very small or empty).

Also, I've done a bit more investigating into the Rails inspector thing - I think that there is a small problem (bug?) in the inspector code. It should be:

Code:

def inspect
    "<MemCache: %d servers, %d buckets, ns: %s, ro: %p>" %
      [@servers.length, @buckets.length, @namespace, @readonly]
  end

The %p specifier for the namespace puts in a string with quotes round it, so I get

"<MemCache: 1 servers, 2 buckets, ns: "blah", ro: false>"

that is, the quote character isn't escaped and it looks to me like

"<MemCache: 1 servers, 2 buckets, ns: "

blah

", ro: false>"

which of course causes me some trouble ...

Dermot

[cfis]

Thanks for the info Dermot - will give it a try.

The next annoyance is that if I set breakpoints in Rails code - say the line I talked about above in session_management or mongrel_rails - all the breakpoints get disabled at start with a message "Language Not Supported."  Once things are started, I can then reenable them.  But it makes it impossible to debug the Rails start up sequence, which I need to do at the moment.  Ideas?

[Dermot]

Charlie,

I may have been a bit over zealous about checking breakpoints here. If I do my normal breakpoint setting method (double click in the widget margin on the left), then the error isn't reported. The only way I can get this to occur is to do something like 'Break at function' when I do get an error like you've reported.

All I can think of here is that VS sometimes isn't filling in the fields in the breakpointstructure that I get from it. I have a feeling that I used to get this, but I don't anymore. Are you using VS 2008 SP1?

All the same, I'll remove this language check in the bug-fix release - it's not very useful.

Dermot