Updating to support Python3 #1

67hz · 2020-03-30T22:04:00Z

updating README
* install notes, lldb help commands, configuration
using pyx to support python/python3
removing pathogen dependency
updating error messages to use pyx
fixing path to python-vim-lldb
moving cursor binding to augroup
this allows targeted unbinding in the case that imports fail
adding bind/unbind ability to cursor
adding entrance guards
vim > v8
check lldb exists before binding and allowing custom path to lldb
* prevents vim lockup if lldb fails to import
fixing buffer append output
lldb output parsing - escaping ansi for cleaner output
adding async user option
updating vimrc customization naming
adding asci escaping to status line output
refactoring sign coloring and adding default hl groups
updating readme for custom overrides
updating lldb commands
bumping required vim down to 8.1.0
updating error messaging

* updating README * install notes, lldb help commands, configuration * using pyx to support python/python3 * removing pathogen dependency * updating error messages to use pyx * fixing path to python-vim-lldb * moving cursor binding to augroup * this allows targeted unbinding in the case that imports fail * adding bind/unbind ability to cursor * adding entrance guards * vim > v8 * check lldb exists before binding and allowing custom path to lldb * prevents vim lockup if lldb fails to import * fixing buffer append output * lldb output parsing - escaping ansi for cleaner output * adding async user option * updating vimrc customization naming * adding asci escaping to status line output * refactoring sign coloring and adding default hl groups * updating readme for custom overrides * updating lldb commands * bumping required vim down to 8.1.0 * updating error messaging

JDevlieghere · 2020-06-19T23:34:46Z

README.md

+vim-lldb
+========
+
+LLDB debugging in Vim for Python2 and Python3.


I think the common formatting is Python 2 and Python 3.

JDevlieghere · 2020-06-19T23:35:28Z

README.md

+    3.7.6 (default, ...)
+
+
+If python versions are mismatched, either recompile Vim to match the same version as LLDB or vice-versa.


You could maybe point to https://lldb.llvm.org/resources/caveats.html for some more details.

JDevlieghere · 2020-06-19T23:36:18Z

python-vim-lldb/import_lldb.py

        if not os.path.exists(lldb_minus_p_path):
            # lldb -P returned invalid path, probably too old
            pass
        else:
            sys.path.append(lldb_minus_p_path)
+            # print("DEBUG: importing from sys.path as lldb: %s"% lldb_minus_p_path)


Let's remove this.

JDevlieghere · 2020-06-19T23:37:15Z

python-vim-lldb/import_lldb.py

@@ -51,10 +60,12 @@ def import_lldb():
        # Unable to import lldb module from path returned by `lldb -P`
        pass

-    # On Mac OS X, use the try the default path to XCode lldb module
+    # On Mac OS X, try the default path to XCode lldb module


s/XCode/Xcode/

JDevlieghere · 2020-06-19T23:38:18Z

python-vim-lldb/import_lldb.py

    if "darwin" in sys.platform:
-        xcode_python_path = "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/Current/Resources/Python/"
+        python_major_version = vim.eval("s:lldb_python_version")
+        xcode_python_path = "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/Current/Resources/Python%s/"% python_major_version


The path for Python 2 is not /Python2/ but just Python, so for Python 2 you'll want to append nothing.

The naming of that variable is a bit misleading. In the case of Python 2 support, it resolves to an empty string. A better name like xcode_path_modifier might make this more clear?

JDevlieghere · 2020-06-19T23:38:30Z

python-vim-lldb/lldb_controller.py

@@ -93,6 +102,7 @@ def completeCommand(self, a, l, p):
        p = int(p) - 1

        result = lldb.SBStringList()
+        # print("DEBUG: completeCommand result : %s"% result)


* updating README * correcting Python, Xcode naming

JDevlieghere

I tried loading the plugin on macOS:

$ defaults write com.apple.dt.lldb DefaultPythonVersion 2 # Force lldb to use Python 2
$ /usr/bin/vim # System vim build against system Python 2

Vim would hang on launch. Have you seen something like this during development? I'll build an lldb against Python 3 (from Homebrew) to try out the Python 3 support.

JDevlieghere · 2020-06-24T16:54:40Z

README.md

+    (lldb) script
+    Python Interactive Interpreter
+    >>> import sys
+    >>> print(svs.version)


s/svs/sys/

We could also make this a one-liner:
lldb -b -o "script import sys; print(sys.version)"

* one liner test for lldb's python interpreter

67hz · 2020-06-24T17:34:34Z

I tried loading the plugin on macOS:
$ defaults write com.apple.dt.lldb DefaultPythonVersion 2 # Force lldb to use Python 2
$ /usr/bin/vim # System vim build against system Python 2
Vim would hang on launch. Have you seen something like this during development? I'll build an lldb against Python 3 (from Homebrew) to try out the Python 3 support.

What version of Vim are you running?
Did the plugin issue an import failure warning? If the import fails for any reason, the plugin should not put Vim in a non-functioning state. It should disable and remove itself from the plugins. If the import succeeded, however, there could be something funky going on.

I believe I used Python 2.7.16 when I tested support originally using Vim 8.2. I'll rebuild with a 2.x and see if I run into this.

67hz · 2020-07-01T18:57:26Z

I tried loading the plugin on macOS:
$ defaults write com.apple.dt.lldb DefaultPythonVersion 2 # Force lldb to use Python 2
$ /usr/bin/vim # System vim build against system Python 2
Vim would hang on launch. Have you seen something like this during development? I'll build an lldb against Python 3 (from Homebrew) to try out the Python 3 support.
What version of Vim are you running?
Did the plugin issue an import failure warning? If the import fails for any reason, the plugin should not put Vim in a non-functioning state. It should disable and remove itself from the plugins. If the import succeeded, however, there could be something funky going on.

I believe I used Python 2.7.16 when I tested support originally using Vim 8.2. I'll rebuild with a 2.x and see if I run into this.

I wonder if setting the defaults to Python 2 as you have done in the bash snippet may be the issue. On your machine, are you able to import lldb as a module from the Python 2 interpreter?

I tried recreating your env: set lldb defaults to Python 2 with lldb compiled against Python 3.
I was not able to import the lldb module into Python 2. In my case, Vim was not able to load the vim-lldb plugin at all, but I would expect this since there isn't a module available to import.

I pulled the latest from the llvm repo to try building lldb fresh against Python 2. I used to set -DPYTHON_EXECUTABLE="/usr/bin/python" to force a build with Python 2, but the current lldb build process ignores that. Do you know if there is another way to specify the Python version in the lldb build?

The only other cause I can think of for the plugin to hang on launching a debug session, is if an admin auth is needed for the lldb cert and the password prompt opens up in the background. Without admin rights, Vim would block until those were granted, i.e., typing in the admin pw.

JDevlieghere · 2020-07-07T17:52:45Z

What version of Vim are you running?

I'm using the system vim in /usr/bin:

/usr/bin/vim --version
VIM - Vi IMproved 8.1 (2018 May 18, compiled Jun  5 2020 21:30:37)

which is compiled with Python 2:

+cmdline_hist      -langmap           +python/dyn        +visual
+cmdline_info      +libcall           -python3           +visualextra

The configuration I'm testing is using only "system" tools, e.g. the vim that ships with macOS and the lldb that ships with Xcode.

Did the plugin issue an import failure warning? If the import fails for any reason, the plugin should not put Vim in a non-functioning state. It should disable and remove itself from the plugins. If the import succeeded, however, there could be something funky going on.

It did not, I just hung until I killed it after a few minutes.

JDevlieghere · 2020-07-07T17:58:24Z

I wonder if setting the defaults to Python 2 as you have done in the bash snippet may be the issue. On your machine, are you able to import lldb as a module from the Python 2 interpreter?

It might be the problem but that's one of the few scenario that we guarantee that should work. Yes, I can import lldb into the system Python 2 interpreter. As explained on https://lldb.llvm.org/resources/caveats.html it is not possible to import it into a third-party (e.g. Homebrew) Python 2 interpreter. T

I tried recreating your env: set lldb defaults to Python 2 with lldb compiled against Python 3.

I was not able to import the lldb module into Python 2. In my case, Vim was not able to load the vim-lldb plugin at all, but I would expect this since there isn't a module available to import.

I pulled the latest from the llvm repo to try building lldb fresh against Python 2. I used to set -DPYTHON_EXECUTABLE="/usr/bin/python" to force a build with Python 2, but the current lldb build process ignores that. Do you know if there is another way to specify the Python version in the lldb build?

This code is not available upstream and only applies to the LLDB shipped in Xcode. Rather than linking statically against one Python version, like the open source version does, it dlopen's a different script interpreter dylib that's build against the system Python 2 or the Xcode Python 3 respectively.

The only other cause I can think of for the plugin to hang on launching a debug session, is if an admin auth is needed for the lldb cert and the password prompt opens up in the background. Without admin rights, Vim would block until those were granted, i.e., typing in the admin pw.

I hadn't reached that point yet but that sounds like a valid concern we should check.

JDevlieghere · 2020-07-07T18:01:06Z

Anyway, the situations that should be guaranteed to work are:

System vim (Py2) and Xcode lldb (Py2 by using the default).
System vim (Py2) and open source LLDB built against system Python 2.
Open source vim (Py2 or Py3) and open source LLDB build against the exact same Python 2 or Python 3.

I checked scenario (1) because it's the easiest to sanity check for users.

67hz · 2020-07-10T19:56:42Z

Anyway, the situations that should be guaranteed to work are:

System vim (Py2) and Xcode lldb (Py2 by using the default).

System vim (Py2) and open source LLDB built against system Python 2.

Open source vim (Py2 or Py3) and open source LLDB build against the exact same Python 2 or Python 3.

I checked scenario (1) because it's the easiest to sanity check for users.

Will do. I have only checked against open souce LLDB builds so I will get all these scenarios sorted then update this PR with any changes.

omartijn · 2020-08-27T19:02:42Z

I've been trying to use this PR, since the vim package on my distribution (debian stable) supports only python 3. I've not been able to get it to work. I'm using the lldb packages from the llvm repo directly and have verified that lldb is linked against the exact same python version.

When I use the version from this PR, vim is somehow messed up. Syntax highlighing doesn't work, and in the bottom of the screen it shows 2,1All. If I attempt to use j or k, the file data disappears and only the line numbers remain. The text in the bottom changes too.

Any guesses as to what is wrong here?

67hz · 2020-08-27T19:48:02Z

I've been trying to use this PR, since the vim package on my distribution (debian stable) supports only python 3. I've not been able to get it to work. I'm using the lldb packages from the llvm repo directly and have verified that lldb is linked against the exact same python version.

When I use the version from this PR, vim is somehow messed up. Syntax highlighing doesn't work, and in the bottom of the screen it shows 2,1All. If I attempt to use j or k, the file data disappears and only the line numbers remain. The text in the bottom changes too.

Any guesses as to what is wrong here?

Does Vim output any error messaging on startup? Also, does the syntax highlighting issue happen after you load a target file?
If you can paste the output of vim --version here, that will help. The issue with 'jk' sounds like a mapping conflict - maybe a setting in .vimrc or through another plugin. Do you have those keys mapped as mode switches? The vim-lldb plugin does not bind to either of those keys by default.

* updating xcode path var * adding native package manager to installation notes

Vim uses 2 single quotes to escape a single quote for use by `echo`. This fixes a bug if LLDB's output contains a single quote, e.g., in a help menu

omartijn · 2020-08-28T18:59:24Z

I don't see any error messages from vim. I have tried opening vim without opening a file, and when I do this, I get the usual startup message, but it's all on the last line (where you normally type commands and see line numbers. I get something like this:

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 0,0-1AllVIM - Vi IMprovedversion 8.1.1401by Bram Moolenaar et al.Modified by [email protected] is open source and freely distributableHelp poor children in Uganda!type :help iccf<Enter> for information type :q<Enter> to exit type :help<Enter> or <F1> for on-line helptype :help version8<Enter> for version info

The vim version used is 8.1 (2018 May 18, compiled Jun 15 2019 16:41:15), which is the version available in the debian stable repository. I have not installed any key mappings. The only entry in .vim/autoload is pathogen.vim, and the only entry in .vim/bundle is the symlink to vim-lldb.

I don't think there's anything special about the j and k keys, or the way they are mapped. It's just that the whole console is somewhat garbled, and doing any kind of cursor movement changes how exactly it's messed up. I get the same thing if I use the arrow-up or arrow-down keys with vim-lldb loaded. Maybe I should have been clearer about this, I also don't think it's syntax highlighting per se that's broken, I think that's just another side-effect of the whole console being garbled.

67hz · 2020-08-30T21:50:51Z

I don't see any error messages from vim. I have tried opening vim without opening a file, and when I do this, I get the usual startup message, but it's all on the last line (where you normally type commands and see line numbers. I get something like this:

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 0,0-1AllVIM - Vi IMprovedversion 8.1.1401by Bram Moolenaar et al.Modified by [email protected] is open source and freely distributableHelp poor children in Uganda!type :help iccf<Enter> for information type :q<Enter> to exit type :help<Enter> or <F1> for on-line helptype :help version8<Enter> for version info

The vim version used is 8.1 (2018 May 18, compiled Jun 15 2019 16:41:15), which is the version available in the debian stable repository. I have not installed any key mappings. The only entry in .vim/autoload is pathogen.vim, and the only entry in .vim/bundle is the symlink to vim-lldb.

I don't think there's anything special about the j and k keys, or the way they are mapped. It's just that the whole console is somewhat garbled, and doing any kind of cursor movement changes how exactly it's messed up. I get the same thing if I use the arrow-up or arrow-down keys with vim-lldb loaded. Maybe I should have been clearer about this, I also don't think it's syntax highlighting per se that's broken, I think that's just another side-effect of the whole console being garbled.

I was able to recreate this with a Red Hat distro. It looks like the debugger hijacks the main Vim thread on initialization. My guess is this will affect any *nix distro. I will work on a patch for this and merge into the PR.

Wentzell · 2021-03-04T14:31:16Z

Any Update on this? Would be great to have this working with Python3.

67hz · 2021-03-14T18:35:13Z

I have a complete rewrite under development right now. This issue and a few other concurrency-related bugs dealing with targeted processes warranted an architectural shift, primarily, to a client/server model. I will post an update here once the plugin reaches a more functional level.

Wentzell · 2021-03-15T14:30:56Z

Thanks for the update! Looking forward to trying the rewrite!

omartijn · 2021-09-29T07:48:37Z

@67hz Please let me know if I can help with anything. I'd be very happy to try things out on a variety of linux setups and with different lldb versions.

67hz · 2021-10-01T14:09:14Z

@omartijn I could definitely use help on platform testing and portability. I will clean up the cruft and shoot over the repo link. It has not reached feature parity with the original, but it does play nice with Vim.

keith · 2022-03-19T22:26:53Z

I've submitted an alternative since I don't think we need to support python2 anymore #4

Aaron Hinojosa added 2 commits March 30, 2020 16:37

updating README for lldb-tools

37d4529

JDevlieghere self-requested a review June 19, 2020 23:32

JDevlieghere reviewed Jun 19, 2020

View reviewed changes

addressing PR comments

feb15e0

* updating README * correcting Python, Xcode naming

JDevlieghere reviewed Jun 24, 2020

View reviewed changes

updating README

11bbff7

* one liner test for lldb's python interpreter

Aaron Hinojosa added 2 commits August 27, 2020 15:05

More PR adjustments

a6c9109

* updating xcode path var * adding native package manager to installation notes

escaping LLDB's output the vim way

c19441d

Vim uses 2 single quotes to escape a single quote for use by `echo`. This fixes a bug if LLDB's output contains a single quote, e.g., in a help menu

This was referenced Mar 19, 2022

Convert to use python3 #4

Merged

Improve error handling #5

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Updating to support Python3 #1

Updating to support Python3 #1

67hz commented Mar 30, 2020

JDevlieghere Jun 19, 2020

JDevlieghere Jun 19, 2020

JDevlieghere Jun 19, 2020

JDevlieghere Jun 19, 2020

JDevlieghere Jun 19, 2020

67hz Jun 22, 2020

JDevlieghere Jun 19, 2020

JDevlieghere left a comment

JDevlieghere Jun 24, 2020

JDevlieghere Jun 24, 2020

67hz commented Jun 24, 2020

67hz commented Jul 1, 2020

JDevlieghere commented Jul 7, 2020

JDevlieghere commented Jul 7, 2020

JDevlieghere commented Jul 7, 2020

67hz commented Jul 10, 2020

omartijn commented Aug 27, 2020

67hz commented Aug 27, 2020

omartijn commented Aug 28, 2020

67hz commented Aug 30, 2020

Wentzell commented Mar 4, 2021

67hz commented Mar 14, 2021

Wentzell commented Mar 15, 2021

omartijn commented Sep 29, 2021

67hz commented Oct 1, 2021

keith commented Mar 19, 2022

		3.7.6 (default, ...)


		If python versions are mismatched, either recompile Vim to match the same version as LLDB or vice-versa.

Updating to support Python3 #1

Are you sure you want to change the base?

Updating to support Python3 #1

Conversation

67hz commented Mar 30, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JDevlieghere left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

67hz commented Jun 24, 2020

67hz commented Jul 1, 2020

JDevlieghere commented Jul 7, 2020

JDevlieghere commented Jul 7, 2020

JDevlieghere commented Jul 7, 2020

67hz commented Jul 10, 2020

omartijn commented Aug 27, 2020

67hz commented Aug 27, 2020

omartijn commented Aug 28, 2020

67hz commented Aug 30, 2020

Wentzell commented Mar 4, 2021

67hz commented Mar 14, 2021

Wentzell commented Mar 15, 2021

omartijn commented Sep 29, 2021

67hz commented Oct 1, 2021

keith commented Mar 19, 2022