Skip to content

Conversation

@avinab-neogy
Copy link
Collaborator

Added lldb debugging functionality

Closes #196 and #30

@avinab-neogy avinab-neogy requested a review from hturner August 11, 2025 07:14
@hturner hturner mentioned this pull request Aug 11, 2025
Copy link
Member

@hturner hturner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is getting close, but we need to avoid hard-coding the root directory.

Another place this needs to change is in the postCreateCommand: use ./scripts/localscript.sh not /workspaces/r-dev-env/scripts/localscript.sh.

Also, delete rm INIT in welcome_message.sh as the INIT file no longer exists (this should have been part of #263 but we can tidy that up here).

@avinab-neogy avinab-neogy self-assigned this Aug 28, 2025
@avinab-neogy
Copy link
Collaborator Author

Hi @hturner ,
I have made all the changes suggested in the review and am testing this out.
Thanks!

@avinab-neogy
Copy link
Collaborator Author

Screenshot from 2025-08-28 14-36-18 Tested out after making the recent changes and it still returns the same error. Screenshot from 2025-08-28 14-36-42

@avinab-neogy
Copy link
Collaborator Author

Hi @hturner ,
I tested this setup using codespaces and after building R from source following the steps from https://contributor.r-project.org/r-dev-env/tutorials/building_r/ and running which_r to select r_devel the process is still selecting the default binary at /usr/bin/R
Screenshot from 2025-08-28 18-40-57
I am still looking into the behavior of which_r to understand why the selection is not updating the terminal to use the built R binary correctly. Will keep you posted once I have more insights!

@hturner
Copy link
Member

hturner commented Aug 28, 2025

which_r changes the R version used in R terminals, which is set by the VS Code setting r.rterm.linux. With this PR, we are fixing r.term.linux to always point to launch_r.sh and using which_r to update the R binary specified in launch_r.sh.

The version of R used in the bash terminal is defined by the path returned by which r, where which is the usual Linux command. This would be replaced by the r-devel version if we used make install after building R. However, we don't want to do this 1) because it would require using sudo, which we shouldn't encourage users to do and 2) because we want to use the release version of R for the packages that we install when setting up the container (see #25 (comment)).

So to check things are working properly:

  1. After running which_r to select the r-devel version, check that launch.sh has been updated as expected (exec /usr/bin/R "$@" replaced with exec /workspaces/r-dev-env/build/r-devel/bin/R "$@")
  2. Launch an R terminal by clicking "R (not attached)" in the status bar or selecting "R: Create R terminal" through the command palette. The r-devel version of R should be launched (which you should see by the version information at the top of the opening message in R). Run Sys.getenv("LD_PRELOAD") and check it is set to "./scripts/allow_ptrace.so". Then LLDB debugging should work!

@avinab-neogy
Copy link
Collaborator Author

avinab-neogy commented Sep 9, 2025

I have updated the relevant section in which_r.sh to modify launch_r.sh so that it correctly sets the R executable for the R terminal. Using [^ ] for pattern matching makes the substitution more precise and reduces the risk of erroneous replacements.

I have updated the devcontainer.json to use bash instead of sh since that was returning an error as well.

@avinab-neogy
Copy link
Collaborator Author

Hi @hturner ,
I know you are busy right now but please check when you are free, I tried building R in codespaces using this feature/lldb-new branch and I am geeting this error and this is suggesting that local_script.sh script is not executable but I don't get this error in the local setup, what should be done here?
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants