VSCode debugger attaches, but breakpoints are ignored

I have installed VS Code and Peng Lv’s Ruby extension v 0.25.3. From a command prompt, I start SketchUp Make 2017 with this:

SketchUp -rdebug "ide port=7000 wait"

SketchUp starts, then blocks waiting for a connection. I then start the debugger in VS Code using this launch configuration:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen for rdebug-ide",
      "type": "Ruby",
      "request": "attach",
      "cwd": "${workspaceRoot}",
      "remoteHost": "127.0.0.1",
      "remotePort": "7000",
      "remoteWorkspaceRoot": "${workspaceRoot}"
    }
  ]
}

SketchUp unblocks and runs normally. In the Ruby Console, I enter this code:

$LOAD_PATH << 'C:/ProgramData/Shared Documents/Ex Lumina/VSCode Projects/SketchUp Boilerplate/sketchup-extension-vscode-project/src'

load 'ex_hello_cube.rb'

This loads the example “hello cube” extension. The Create Cube Example menu entry appears at the end of SketchUp’s Extensions menu, and the extension runs correctly when I click on that entry.

If I change the code in the extension’s ex_hello_cube/main.rb file and enter load 'ex_hello_cube/main.rb' in the Ruby console, then run the extension again, my changes take effect.

However, if I add breakpoints to the code in VSCode, they are ignored when I run the extension. The red dots appear in VSCode’s gutter and the breakpoints are listed at the bottom the Debug sidebar.

In the Ruby console, I can also run this code:

require 'socket'
module MeMeMe 
  s = TCPSocket.new 'localhost', 7000

  s.puts('break')     # send a 'break command' to the SU debugger
  line = s.gets       # Read lines from socket
  puts line           # and print them

  s.close             # close socket when done
end

The above prints this result:

<breakpoints></breakpoints>

The VSCode debugger does stop at breakpoints in my Ruby programs that are not SketchUp extensions.

NOTE: I installed SURubyDebugger.dll into my SketchUp executable’s folder. I downloaded it from the releases page on GitHub. The notes at the actual repository state that I must use version 1.1.0.0 with VS Code. However, the Windows properties sheet for the version available at the releases page says it is version 1.0.2.0. I am unable to find a binary of version 1.1.0.0. If that’s the cause of my problem, then if anyone can direct me to a Windows 64-bit version 1.1.0.0 of SURubyDebugger.dll, I’d be most grateful.

I would also be very grateful for any other help in figuring out why the breakpoints aren’t having any effect in my SketchUp extensions.

Thanks.

Further to the above: I downloaded the .zip of the Visual Studio solution from the releases page. Although its root directory name is “sketchup-ruby-debugger-1.1.0.0,” its Resource.rc file contains this:

VS_VERSION_INFO VERSIONINFO
 FILEVERSION 1,0,2,0
 PRODUCTVERSION 1,0,2,0
 FILEFLAGSMASK 0x3fL
#ifdef _DEBUG
 FILEFLAGS 0x1L
#else
 FILEFLAGS 0x0L
#endif
 FILEOS 0x40004L
 FILETYPE 0x2L
 FILESUBTYPE 0x0L
BEGIN
    BLOCK "StringFileInfo"
    BEGIN
        BLOCK "040904b0"
        BEGIN
            VALUE "CompanyName", "Trimble Navigation Ltd."
            VALUE "FileDescription", "SketchUp Ruby Debugger Engine"
            VALUE "FileVersion", "1.0.2.0"
            VALUE "InternalName", "SURubyDebugger.dll"
            VALUE "LegalCopyright", "Copyright (C) 2014 Trimble Navigation Ltd."
            VALUE "OriginalFilename", "SURubyDebugger.dll"
            VALUE "ProductName", "SketchUp Ruby Debugger Engine"
            VALUE "ProductVersion", "1.0.2.0"
        END
    END
    BLOCK "VarFileInfo"
    BEGIN
        VALUE "Translation", 0x409, 1200
    END
END

So I have to admit I don’t even know if this will build version 1.1.0.0 or 1.0.2.0.

I seem to remember reporting that the internal version number was incorrect. Looks like the problem never got solved.

There is at least 1 open issue involving breakpoints (but it seems the problem lies with the VSCode extension not the SU Debugger DLL.)

There is also a vague TODO list at the bottom of the repo’s README.

I’m struggling with compiling the source now. Some of the usual “upgrade” issues are in play, since it was created with an earlier version of the compiler, it seems. Had to edit one of the include directories. For some reason, it is also set to Win32 when I think it has to be x64. Also, it’s set to Debug, not Release. I’ll keep trying. Even if I can’t get it to compile, maybe I’ll learn something useful.

Any ideas on why my breakpoints are ignored? What are you using for debugging Ruby extensions?

Thanks for the reply!

Ah! Reading that thread, I see a passing suggestion that path names might be an issue. This jogged a memory I had about not installing Ruby itself into a path with spaces (like, say, “C:\Program Files”). My extension code is in a path with spaces. I moved it to a path with no spaces and the breakpoints started working.

Does Ruby not play well with paths that have spaces in them?

1 Like

I’ve always tried to let the Ruby Installer install into root folders using it’s naming convention, ie "Ruby26-x64",
… except when I purposefully need to have 2 minor releases installed … ie, "Ruby255-x64" and "Ruby257-x64", This is a pain because the installers are not setup to do this. So one needs to install one version, then copy it to a new folder adding the minor number, then install the other minor and copy and rename again.
Then use a utility like uru to switch between the versions.

Well, I think that if you have the Ruby DevKit installed, it’s batch initialization script may not expect spaces.

But, generally if the pathstring is quoted, spaces shouldn’t be an issue. Ie, we see more problems with backslashes which are interplolated as special characters (\r, \n, etc.) or unicode characters (\u).

I myself have never tried to use breakpoints.

Hmmm. Interesting. Glad you got it working. (Give yourself the solution mark.)

Also, … you may help by opening an issue in the repo issues that spaces in paths prevented breakpoints from working.

Good Lord, man, how do you debug your code without them?

I may have spoken too soon. I tried to reproduce the bug by adding a space and it didn’t come back. I will explore this some more and, if I can reproduce it reliably, I’ll add an issue to the repo.

Most mistakes I make are typos that cause SyntaxErrors, NameError or the like that manifest when loading the code, which the debugger doesn’t help with (uh, … since the code doesn’t load.) So I just keep loading manually fixing each error that pops up until the code loads okay.

Often I find it easier to just insert puts statements into the code to track down RuntimeErrors. So most the time I’m using a “plain jane” Notepad++ editor. (Got used to this way because the SURubyDeugger didn’t get implemented until 2014 or so.)

That’s the default of Visual Studio. Setting the x64/win32 and debug/release is a user-local setting that isn’t checked into version control.

Not sure… Whenever I’ve run into that it’s becaused I set breakpoints in files different from what SketchUp loaded. But then the breakpoint would not appear completely red. (I assume your doesn’t change once it’s all loaded?)

VSCode - I usually used that VSCode example repo as a base for new extensions or adding debugging to existing extensions.

Whoa, that part I’ve put in bold really caught my eye. How does that example repo help in adding debugging?

I guess it just adds the .vscode directory that contains launch.json and tasks.json, to his extensions

This is BTW how my launch.json looks like:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for rdebug-ide",
            "type": "Ruby",
            "request": "attach",
            "cwd": "${workspaceRoot}",
            "remoteHost": "127.0.0.1",
            "remotePort": "7000",
            "remoteWorkspaceRoot": "${workspaceRoot}"     
        }
    ]
}

and this is my tasks.json:

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "launch_SU17",
            "type": "shell",
            "command": "open \"/Applications/SketchUp 2017/SketchUp.app\" --args -RubyStartup \"$PWD/launch.rb\"",
            "windows": {
                "command": "./launch_SU17.bat"
            },
            "problemMatcher": []
        },
        {
            "label": "launch_SU18",
            "type": "shell",
            "command": "open \"/Applications/SketchUp 2018/SketchUp.app\" --args -RubyStartup \"$PWD/launch.rb\"",
            "windows": {
                "command": "./launch_SU18.bat"
            },
            "problemMatcher": []
        },
        {
            "label": "launch_SU19",
            "type": "shell",
            "command": "open \"/Applications/SketchUp 2019/SketchUp.app\" --args -RubyStartup \"$PWD/launch.rb\"",
            "windows": {
                "command": "./launch_SU19.bat"
            },
            "problemMatcher": []
        }
    ]
}

I have done nothing special besides puttin the .ddl in the sketchup application folder AND installing the rebornix.ruby vscode extension: Ruby - Visual Studio Marketplace

Oh, the .bat files look like this:

c:
cd C:\Program Files\SketchUp\SketchUp 2017\
SketchUp.exe -rdebug "ide port=7000" -RubyStartup "%~dp0launch.rb"

This is ugly, but it works for me. It launches SketchUp and tells it to load launch.rb that is located in the same directory as the .bat file. launch.rb has this content:

require "sketchup"

timer_id = UI.start_timer(0, false) {
	
	# always show the console
	SKETCHUP_CONSOLE.show

	# stop the timer
	UI.stop_timer(timer_id)
	
	src_folder = "#{File.dirname(__FILE__)}/src_extension/"
	extension_files = Dir[src_folder + "*.rb"]

	extension_files.each do |f|
		extension_name = File.basename( f, ".*" )
		extension_folder = "#{src_folder}#{extension_name}"
		$LOAD_PATH << extension_folder
		require f
	end #do

	perform_tests();
}

def perform_tests()

end #def

This basically loads all .rb files in the local ./src_extension dir. It also expects there to be a folder with the same name as the .rb, which should be the case for every extension. Finally, it adds that folder to $LOAD_PATH although that should not be needed since I use require_relative in every file

As Kenny mentioned, I use it to quickly drop VSCode config into a project. That along with RuboCop and SolarGraph config for linting and code insight.

Steven, I wonder if your issue was related to this?

I looked at that earlier but, to be honest, I really couldn’t understand what the problem was there. Mine seems somewhat simpler. The path that my project was on included a “junction” symbolic link from the C: drive to a folder on the D: drive. Maybe that confused it. Unfortunately, I am finding that getting VS Code set up to even be a “real” Ruby IDE is a lot more work than I had expected. You have to download several plug-ins, then configure them, then… well, I just don’t need another hobby at this time, you know?

Going to put this aside for a while, actually. I’d love to write some SketchUp extensions, but it’s not a high priority and, until a good, inexpensive Ruby IDE shows up that works out-of-the-box, I just don’t have time to fuss with things that call for a lot of study and twiddling. (Oh, I tried “Komodo” this morning. Don’t anyone waste your time. Even the start-up “tutorial” doesn’t work.)

I did a post about setting up NetBeans. That would be an option if VS Code is too frustrating for you.

I would have loved to use NetBeans for Ruby, but they have dropped support for it and the plug-in is no longer available.

I just set up VS Code on a new machine, and it’s really not that bad. It took 11 minutes to download and install, and get everything set up. That included installing, Ruby, and Git as well as VS Code. It took another 8 minutes to clone my project and do my first debug run.

Granted my first install took longer than that, but over all I’d say it’s not too bad.

Well, now you’ve done it! Count on me to come back here and pester you for guidance when I can’t get it working as quickly as you did :slight_smile: .

The VSCode example project on GitHub will recommend extensions that you can Install All.

Maybe you’re on to something there…

Could you try the example VSCode project without any symbolic links in the path?