profile
viewpoint

vadimcn/cargo-pgo 25

Supercharge you Rust programs!

vadimcn/llvm 12

Temporary fork of LLVM for Rust

vadimcn/compiler-rt 3

Mirror of official compiler-rt git repository located at http://llvm.org/git/compiler-rt. Updated hourly.

vadimcn/rust 2

a safe, concurrent, practical language

vadimcn/awesome-rust 1

A curated list of Rust code and resources.

vadimcn/clang 0

Mirror of official clang git repository located at http://llvm.org/git/clang. Updated every five minutes.

vadimcn/compiler-builtins 0

Porting `compiler-rt` intrinsics to Rust

issue closedvadimcn/vscode-lldb

Json allows no comments :-)

https://github.com/vadimcn/vscode-lldb/blob/004de538b7ed96f7aa7aa97cc661631800307ee8/.vscode/launch.json#L25

closed time in a day

ggreif

issue commentvadimcn/vscode-lldb

Json allows no comments :-)

VSCode uses JSONC.

ggreif

comment created time in a day

issue openedmicrosoft/vscode-python

Support custom object views in the debugger.

Sometimes the built-in implementation of __repr__ for a data type does not display the right information. For example, PyTorch's Tensor prints element values, which are pretty useless once tensor size grows beyond about 3x3. At that point, the shape of the tensor becomes a much more interesting piece of information. Unfortunately, shape is not included in the default repr for Tensors.

It would be nice if we could customize how objects are displayed in the debugger.

One possible implementation: inject user-provided Python module into the debuggee process, have the debugger use a function from that module as a decorator for all variables/expressions it displays. The decorator would have the choice to either return the argument unchanged, or to return a string that overrides the default view. ...Or maybe it could even return an entirely new proxy object, whose properties would be displayed instead of the original object.

created time in 3 days

GollumEvent
GollumEvent
GollumEvent

push eventvadimcn/vscode-lldb

vadimcn

commit sha c0ff754c1a72c2b4078bbca90491cfed9a4e6d1a

Add URL of the Troubleshooting page.

view details

push time in 3 days

PR closed vadimcn/vscode-lldb

Remove unnecessary unstable features

Most unstable features listed are not used and this PR remove them.

We currently only requires untagged_unions. It is possible to be removed by using [u64; 2] for SBValue with some transmutes, and I'm happy to do it. Then the whole rust crate can be compiled by current stable rustc. But I'm not sure if it is worth it.

+1 -4

1 comment

2 changed files

oxalica

pr closed time in 4 days

pull request commentvadimcn/vscode-lldb

Remove unnecessary unstable features

Can't seem to resolve this merge... I'll just pick up these changes manually. Thanks!

oxalica

comment created time in 4 days

push eventoxalica/vscode-lldb

Vadim Chugunov

commit sha df46d70e5e23f62cb47a892e55e161428f8df6a7

Add objective-cpp

view details

Vadim Chugunov

commit sha c8e718322252b437a0b564e4316931eca63e18b3

Use enums for Python interface.

view details

Vadim Chugunov

commit sha 53b92615b5b851688b4a1d569e704d6fa8128209

Compile python expressions, allow statements.

view details

Vadim Chugunov

commit sha 6c9edef5e3331665c6b821785dfbbb9a706f515e

Use readline for cargo output parsing.

view details

Vadim Chugunov

commit sha 243806a385e74d6136f5f1538b2677b110e3ce29

Start accepting connections before launching terminal agent.

view details

Vadim Chugunov

commit sha 2c447f6ecc4d81386cc4113573ccd78281cb53c7

Symbols

view details

Vadim Chugunov

commit sha 2b73ca50b76a9fdc3219a0bbbf4c79bd476e5854

linux-builder

view details

Vadim Chugunov

commit sha 4f9299d3c4a2a645b25088776e71a90f0e999cee

Remove xrange.

view details

Vadim Chugunov

commit sha 02adc783d15643c3c93c91aa911af087f5d7fd4f

Embed Python.

view details

Vadim Chugunov

commit sha 6003c774e0611a74c2e9093938801edd3cc83b55

LLDB 1356

view details

Vadim Chugunov

commit sha 0abc4183cdea74698f3762cdba7ff996b4da6147

Dependency tests.

view details

Vadim Chugunov

commit sha bb54a972ff5b8bdf97297745aa602db9236471f7

Await logging in tests.

view details

Vadim Chugunov

commit sha 43446bb5c335131da7c4e6e75fa5edd4f3d1cafe

Fix Windows

view details

Vadim Chugunov

commit sha f4ccd6b5b3be6c5fc8f1030a96a91b11c42de255

Update lockfiles.

view details

Vadim Chugunov

commit sha ee15b5c64be868e0a85d96fc0bab422d1edff31b

Build cpp in debug.

view details

Vadim Chugunov

commit sha 219472133849dd155298ff898f178d4a97c5c188

Deal with PYTHON* env variables.

view details

Vadim Chugunov

commit sha 0fad2fb8df5f4457014df831adc4beadec420ddf

Keep rust.py Py2-compatible.

view details

Vadim Chugunov

commit sha f84edf7e4acbb52e1436666fb7fc0fc4ee6745cd

Implement readMemory

view details

Vadim Chugunov

commit sha 6d425589ed8c9589b72b0b604562f39596797330

Use filesystem casing for paths returned to VSCode on Windows.

view details

Vadim Chugunov

commit sha ecffa9d27123f8366a4f758af280ce3d261c34f0

Implement cancellation.

view details

push time in 4 days

issue commentvadimcn/vscode-lldb

Custom LLDB formatters not loading from the ~/.lldbinit file

My current thinking is this: dotfiles are fine for CLI tools, but since Codelldb is a VSCode extension, it it appropriate for it use the standard VSCode configuration storage mechanisms. And you can always get the behavior you want - by adding a single line into VSCode's user-level configuration file (not in launch.json - that's for individual launch configurations).

mbargiel

comment created time in 8 days

issue commentvadimcn/vscode-lldb

Complex conditional breakpoints always trigger

Please see the expressions section in the manual. "Simple" expressions don't support invoking object methods. You'll need to use "native" expressions to achieve what you want (i.e. prefix the breakpoint condition with /nat)

tkreind

comment created time in 9 days

push eventvadimcn/vscode-lldb

Vadim Chugunov

commit sha 85f6ed7acdfae7b25a51deb1c43775bb9c684fec

Update issue templates.

view details

push time in 11 days

delete branch vadimcn/vscode-lldb

delete branch : mypy

delete time in 11 days

delete branch vadimcn/vscode-lldb

delete branch : wip

delete time in 11 days

delete branch vadimcn/vscode-lldb

delete branch : vadimcn-patch-1

delete time in 11 days

PR closed vadimcn/vscode-lldb

Update issue templates
+36 -0

0 comment

2 changed files

vadimcn

pr closed time in 11 days

delete branch vadimcn/vscode-lldb

delete branch : templates

delete time in 11 days

PR opened vadimcn/vscode-lldb

Update issue templates
+36 -0

0 comment

2 changed files

pr created time in 11 days

push eventvadimcn/vscode-lldb

vadimcn

commit sha 9abeafb5645a0339fd6be90ba37d793fe8f34a28

Update issue templates

view details

push time in 11 days

create barnchvadimcn/vscode-lldb

branch : vadimcn-patch-1

created branch time in 11 days

issue commentvadimcn/vscode-lldb

[Feature Request] Add preference to allow using the system LLDB on macOS

Yeah, Python is not bundled. Have you tried replacing liblldb? You can also do this manually by setting lldb.library.

Actually, the library you've used before, liblldbPluginScriptInterpreterPython3.dylib, looks like an instance of liblldb, not a Python runtime. I wonder if its symbols simply took precedence over the bundled liblldb because of having been loaded first.

alexfusco5

comment created time in 11 days

issue commentvadimcn/vscode-lldb

Launch or attach target using bazel run does not work

Cargo has a mode in which it logs compilation outputs in JSON format, which is parsed by CodeLLDB and used to locate the binary to launch. As far as I know, Bazel does not provide anything like that.

This might help in your case. If you can find a way to inject a custom wrapper script into bazel run, you could use the uri interface to start a debug session. In the worst case, you could put debugger attach into your binary (see the first example).

JanJamaszyk-FlyNow

comment created time in 11 days

issue closedvadimcn/vscode-lldb

Please merge the pretty printers from the LLDB project

The pretty printers provided by this project do not work with many kinds of types, especially HashMaps. To fix my issues I've just merged the HashMap part from the LLDB project and now all HashMaps are displayed in the debugger as expected.

closed time in 12 days

brmmm3

issue commentvadimcn/vscode-lldb

Please merge the pretty printers from the LLDB project

Should be fixed in v1.6

brmmm3

comment created time in 12 days

issue commentvadimcn/vscode-lldb

Breakpoints Not Stopping (Rust, MacOS)

Yeah, looks like a lldb problem. Please try v1.6, it's based on lldb 11.0, maybe this got fixed.

dan-fritchman

comment created time in 12 days

issue commentvadimcn/vscode-lldb

Launch or attach target using bazel run does not work

You've set up launch config to debug bazel itself, not the process it runs. lldb currently does not support debugging of child processes. You will need to locate the actual executable under bazel-bin/<package path>/<target name> and launch it directly.

JanJamaszyk-FlyNow

comment created time in 12 days

issue closedvadimcn/vscode-lldb

Prepackaged liblldb.so can't find sources for C++ binaries built with `-Wl,--compress-debug-sections=zlib`.

OS: Ubuntu Linux 18.04.4 VSCode version: 1.48.1 Extension version: 1.5.3 Toolchain version: clang version 10.0.0 Build target: x86_64-unknown-linux-gnu Python version: 3.6.9

When C++ binaries are built (in my case, with clang) with the linker flag --compress-debug-sections=zlib (see https://man7.org/linux/man-pages/man1/ld.1.html for more information), the source code will be unavailable to the build of liblldb.so packaged with the vscode-lldb extension.

In particular, the source code display in VS Code shows ; Source location: unknown at the top of it, and when I run the version of lldb from ~/.vscode-server/extensions/vadimcn.vscode-lldb-1.5.3/lldb/bin/lldb, it shows the error message Unable to initialize decompressor for section '.debug_info': zlib is not available.

I can verify that removing --compress-debug-sections=zlib from the build resolves the issue, but of course, it would be great if I could leave it in. I've also verified that the system build of lldb-10 does not have an issue with the compressed debug sections.

closed time in 12 days

aabtop

issue commentvadimcn/vscode-lldb

[Feature Request] Add preference to allow using the system LLDB on macOS

debugserver is the process doing actual debugging, I'd have expected it to be the one whos privileges matter. CodeLLDB (or lldb for that matter) is just the UI.

If MacOS somehow propagates the permissions of debugserver's parent process(es), you could try remote-debugging, i.e. launch debugserver from terminal, attach to it as if debugging on a remote machine, etc.

Not sure what else could be done here...

alexfusco5

comment created time in 12 days

issue commentvadimcn/vscode-lldb

[Linux] Debug Adapter Crashing on Command Completions

Yes, the crash is in liblldb, so it should be reproducible with CLI lldb as well. Maybe even with the one you've compiled locally.

Sorry, currently there isn't a setting to turn off auto-complete. You can try prefixing your commands with a space, that should suppress completions.

penagos

comment created time in 12 days

issue commentvadimcn/vscode-lldb

[Linux] Debug Adapter Crashing on Command Completions

Any idea, which parts of your setup are important for reproducing this? For example, does it have to be opt, or will any program compiled with the same toolchain cause the crash? I assume gcc-produced binaries don't cause problems?

penagos

comment created time in 12 days

issue commentvadimcn/vscode-lldb

No output to DebugConsole on Windows

Ah, hm. I guess one of the two needs to be fixed. :)

dstodev

comment created time in 13 days

issue commentvadimcn/vscode-lldb

No output to DebugConsole on Windows

GTest outputs to stderr, and stderr goes to LLDB log pane, yes. I'd suggest using "terminal": "integrated" instead.

dstodev

comment created time in 13 days

GollumEvent
GollumEvent
GollumEvent
GollumEvent
GollumEvent
GollumEvent
GollumEvent
GollumEvent

issue commentvadimcn/vscode-lldb

Debug Swift

Please upgrade to v1.6 and try again.. I've tested with Swift 5.3.

lokinfey

comment created time in 13 days

issue closedvadimcn/vscode-lldb

LLDB10.0 from Swift5.3 crashes at start

OS: Ubuntu 20.04 VSCode version: 1.49.0 Extension version: 1.5.3 Toolchain version: Swift version 5.3 (swift-5.3-RELEASE) Build target: x86_64-unknown-linux-gnu Python version: 3.8.2 LLDB version: 10.0.0 (git@github.com:apple/llvm-project.git revision c39a810ec308dd4a8d93c5011fb73a5c987e8680)

I can't get the extensions to run because the wrong Python version is found. I have Lldb:Libpython set to /lib/x86_64-linux-gnu/libpython2.7.so.1.0 Which unfortunately has no influence.

liblldb: /usr/lib/liblldb.so
libpython: null
environment: {}
params: {}
[2020-09-17T10:28:04Z INFO  codelldb::find_python] Querying python sysconfig
[2020-09-17T10:28:04Z INFO  codelldb::find_python] Query returned ["libpython3.8.so.1.0"]
[2020-09-17T10:28:04Z INFO  codelldb::find_python] Probing "libpython3.8.so.1.0"
[2020-09-17T10:28:04Z INFO  codelldb::find_python] Py_GetVersion returned "3.8.2 (default, Jul 16 2020, 14:00:26) \n[GCC 9.3.0]"
[2020-09-17T10:28:04Z INFO  codelldb::find_python] Parsed version as 3.8
[2020-09-17T10:28:04Z INFO  codelldb::find_python] Accepted
Listening on port 38515
[2020-09-17T10:28:04Z DEBUG codelldb] New debug session
Fatal Python error: PyThreadState_Get: no current thread
Received signal: SIGABRT
   0: codelldb::hook_crashes::handler
   1: <unknown>
   2: gsignal
   3: abort
   4: Py_FatalError
   5: PyThreadState_Get
   6: Py_InitModule4_64
   7: init_lldb
   8: _ZN12lldb_private27ScriptInterpreterPythonImpl17InitializePrivateEv
   9: _ZN12lldb_private27ScriptInterpreterPythonImplC2ERNS_8DebuggerE
  10: _ZN12lldb_private27ScriptInterpreterPythonImpl14CreateInstanceERNS_8DebuggerE
  11: _ZN12lldb_private13PluginManager31GetScriptInterpreterForLanguageEN4lldb14ScriptLanguageERNS_8DebuggerE
  12: _ZN12lldb_private8Debugger20GetScriptInterpreterEbN4llvm8OptionalIN4lldb14ScriptLanguageEEE
  13: _ZN33CommandObjectCommandsScriptImport9DoExecuteERN12lldb_private4ArgsERNS0_19CommandReturnObjectE
  14: _ZN12lldb_private19CommandObjectParsed7ExecuteEPKcRNS_19CommandReturnObjectE
  15: _ZN12lldb_private18CommandInterpreter13HandleCommandEPKcNS_8LazyBoolERNS_19CommandReturnObjectEPNS_16ExecutionContextEbb
  16: _ZN4lldb20SBCommandInterpreter13HandleCommandEPKcRNS_18SBExecutionContextERNS_21SBCommandReturnObjectEb
  17: _ZN4lldb20SBCommandInterpreter13HandleCommandEPKcRNS_21SBCommandReturnObjectEb
  18: __cpp_closure_8324812709926371778
  19: lldb::strings::with_cstr
  20: lldb::sbcommandinterpreter::SBCommandInterpreter::handle_command
  21: codelldb::python::initialize
  22: codelldb::debug_session::DebugSession::run
  23: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  24: tokio::runtime::thread_pool::ThreadPool::block_on
  25: tokio::runtime::context::enter
  26: tokio::runtime::handle::Handle::enter
  27: entry
  28: codelldb::main
  29: std::rt::lang_start::{{closure}}
  30: std::rt::lang_start_internal
  31: main
  32: __libc_start_main
  33: _start

Debug adapter exit code=255, signal=null.

closed time in 13 days

damuellen

issue commentvadimcn/vscode-lldb

LLDB10.0 from Swift5.3 crashes at start

Duplicate of #344.

damuellen

comment created time in 13 days

issue closedvadimcn/vscode-lldb

swift debug error

my settings.json:

{ "window.zoomLevel": 0, "editor.renderWhitespace": "all", "editor.largeFileOptimizations": false, "python.pythonPath": "/home/lokinfey/.pyenv/versions/3.8.2/bin/python3", "terminal.integrated.inheritEnv": false, "sde.languageServerMode": "sourcekit-lsp", "sourcekit-lsp.serverPath": "/home/lokinfey/Desktop/File/Dev/tools/swift/swiftlang/usr/bin/sourcekit-lsp", "sourcekit-lsp.toolchainPath": "/home/lokinfey/Desktop/File/Dev/tools/swift/swiftlang/", "swift.languageServerPath": "", "swift.path.swift_driver_bin": "/home/lokinfey/Desktop/File/Dev/tools/swift/swiftlang/usr/bin/swift", "lldb.executable": "/home/lokinfey/Desktop/File/Dev/tools/swift/swiftlang/usr/bin/lldb", "lldb.adapterEnv": { "LLDB_DEBUGSERVER_PATH": "/home/lokinfey/Desktop/File/Dev/tools/swift/swiftlang/usr/bin/lldb-server" }, "lldb.launch.expressions": "simple", "lldb.verboseLogging": true, "telemetry.enableTelemetry": false, "[swift]": {}, "lldb.library": "/home/lokinfey/Desktop/File/Dev/tools/swift/swiftlang/usr/lib/liblldb.so.10.0.0git", "lldb.libpython": "/home/lokinfey/.pyenv/versions/3.8.2/lib/libpython3.8.so.1.0" }

when I debug it shows :

configuration: { type: 'lldb', request: 'launch', name: 'Debug', program: '${workspaceFolder}/.build/debug/Run', args: [], cwd: '${workspaceFolder}', preLaunchTask: 'vapor-build', expressions: 'simple', relativePathBase: '/home/lokinfey/Desktop/hello' } liblldb: /home/lokinfey/Desktop/File/Dev/tools/swift/swiftlang/usr/lib/liblldb.so.10.0.0git libpython: null environment: { LLDB_DEBUGSERVER_PATH: '/home/lokinfey/Desktop/File/Dev/tools/swift/swiftlang/usr/bin/lldb-server' } params: {} [2020-09-30T08:44:04Z INFO codelldb::find_python] Querying python sysconfig [2020-09-30T08:44:05Z INFO codelldb::find_python] Query returned ["libpython3.8.so.1.0"] [2020-09-30T08:44:05Z INFO codelldb::find_python] Probing "libpython3.8.so.1.0" [2020-09-30T08:44:05Z INFO codelldb::find_python] Py_GetVersion returned "3.8.2 (default, Jul 16 2020, 14:00:26) \n[GCC 9.3.0]" [2020-09-30T08:44:05Z INFO codelldb::find_python] Parsed version as 3.8 [2020-09-30T08:44:05Z INFO codelldb::find_python] Accepted Listening on port 43219 [2020-09-30T08:44:05Z DEBUG codelldb] New debug session Fatal Python error: PyThreadState_Get: no current thread Received signal: SIGABRT 0: codelldb::hook_crashes::handler 1: <unknown> 2: gsignal 3: abort 4: Py_FatalError 5: PyThreadState_Get 6: Py_InitModule4_64 7: init_lldb 8: _ZN12lldb_private27ScriptInterpreterPythonImpl17InitializePrivateEv 9: _ZN12lldb_private27ScriptInterpreterPythonImplC2ERNS_8DebuggerE 10: _ZN12lldb_private27ScriptInterpreterPythonImpl14CreateInstanceERNS_8DebuggerE 11: _ZN12lldb_private13PluginManager31GetScriptInterpreterForLanguageEN4lldb14ScriptLanguageERNS_8DebuggerE 12: _ZN12lldb_private8Debugger20GetScriptInterpreterEbN4llvm8OptionalIN4lldb14ScriptLanguageEEE 13: _ZN33CommandObjectCommandsScriptImport9DoExecuteERN12lldb_private4ArgsERNS0_19CommandReturnObjectE 14: _ZN12lldb_private19CommandObjectParsed7ExecuteEPKcRNS_19CommandReturnObjectE 15: _ZN12lldb_private18CommandInterpreter13HandleCommandEPKcNS_8LazyBoolERNS_19CommandReturnObjectEPNS_16ExecutionContextEbb 16: _ZN4lldb20SBCommandInterpreter13HandleCommandEPKcRNS_18SBExecutionContextERNS_21SBCommandReturnObjectEb 17: _ZN4lldb20SBCommandInterpreter13HandleCommandEPKcRNS_21SBCommandReturnObjectEb 18: __cpp_closure_8324812709926371778 19: lldb::strings::with_cstr 20: lldb::sbcommandinterpreter::SBCommandInterpreter::handle_command 21: codelldb::python::initialize 22: codelldb::debug_session::DebugSession::run 23: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll 24: tokio::runtime::thread_pool::ThreadPool::block_on 25: tokio::runtime::context::enter 26: tokio::runtime::handle::Handle::enter 27: entry 28: codelldb::main 29: std::rt::lang_start::{{closure}} 30: std::rt::lang_start_internal 31: main 32: __libc_start_main 33: _start

Debug adapter exit code=255, signal=null.

I change s4tf ,it can run ,but it can not show local variable value ,it said <Unable to determine byte size.> . I write vapor project , but I change ide to CLion ...... it has the same error ........... I think it is lldb problem , I retry to build swift with lldb , the version is the same problem

closed time in 13 days

lokinfey

issue commentvadimcn/vscode-lldb

swift debug error

Looks like a duplicate of #344.

lokinfey

comment created time in 13 days

issue commentvadimcn/vscode-lldb

Error when applying LLDB backend for Swift (Using Remote Tools)

I've checked out the latest Swift toolchain for Linux, and it has the same problem. Looks like they forgot to include the requisite Python modules with Swift lldb... probably the same on Windows.

Until this is fixed, the automatic setup won't work. However, you can still locate liblldb.dll in Swift distribution and point codelldb to it via the "lldb.library" configuration setting.

mrbass21

comment created time in 13 days

delete tag vadimcn/vscode-lldb

delete tag : v1.2.0-alpha

delete time in 13 days

delete tag vadimcn/vscode-lldb

delete tag : v1.4.3-dev

delete time in 13 days

delete tag vadimcn/vscode-lldb

delete tag : v1.4.1-dev

delete time in 13 days

delete tag vadimcn/vscode-lldb

delete tag : v1.5.0-dev

delete time in 13 days

delete tag vadimcn/vscode-lldb

delete tag : v1.6.0-dev+200901.0353

delete time in 13 days

delete tag vadimcn/vscode-lldb

delete tag : v1.6.0-dev.201009.2200

delete time in 13 days

delete tag vadimcn/vscode-lldb

delete tag : v1.6.0-dev.2010130059

delete time in 13 days

push eventvadimcn/vscode-lldb

Vadim Chugunov

commit sha df46d70e5e23f62cb47a892e55e161428f8df6a7

Add objective-cpp

view details

Vadim Chugunov

commit sha c8e718322252b437a0b564e4316931eca63e18b3

Use enums for Python interface.

view details

Vadim Chugunov

commit sha 53b92615b5b851688b4a1d569e704d6fa8128209

Compile python expressions, allow statements.

view details

Vadim Chugunov

commit sha 6c9edef5e3331665c6b821785dfbbb9a706f515e

Use readline for cargo output parsing.

view details

Vadim Chugunov

commit sha 243806a385e74d6136f5f1538b2677b110e3ce29

Start accepting connections before launching terminal agent.

view details

Vadim Chugunov

commit sha 2c447f6ecc4d81386cc4113573ccd78281cb53c7

Symbols

view details

Vadim Chugunov

commit sha 2b73ca50b76a9fdc3219a0bbbf4c79bd476e5854

linux-builder

view details

Vadim Chugunov

commit sha 4f9299d3c4a2a645b25088776e71a90f0e999cee

Remove xrange.

view details

Vadim Chugunov

commit sha 02adc783d15643c3c93c91aa911af087f5d7fd4f

Embed Python.

view details

Vadim Chugunov

commit sha 6003c774e0611a74c2e9093938801edd3cc83b55

LLDB 1356

view details

Vadim Chugunov

commit sha 0abc4183cdea74698f3762cdba7ff996b4da6147

Dependency tests.

view details

Vadim Chugunov

commit sha bb54a972ff5b8bdf97297745aa602db9236471f7

Await logging in tests.

view details

Vadim Chugunov

commit sha 43446bb5c335131da7c4e6e75fa5edd4f3d1cafe

Fix Windows

view details

Vadim Chugunov

commit sha f4ccd6b5b3be6c5fc8f1030a96a91b11c42de255

Update lockfiles.

view details

Vadim Chugunov

commit sha ee15b5c64be868e0a85d96fc0bab422d1edff31b

Build cpp in debug.

view details

Vadim Chugunov

commit sha 219472133849dd155298ff898f178d4a97c5c188

Deal with PYTHON* env variables.

view details

Vadim Chugunov

commit sha 0fad2fb8df5f4457014df831adc4beadec420ddf

Keep rust.py Py2-compatible.

view details

Vadim Chugunov

commit sha f84edf7e4acbb52e1436666fb7fc0fc4ee6745cd

Implement readMemory

view details

Vadim Chugunov

commit sha 6d425589ed8c9589b72b0b604562f39596797330

Use filesystem casing for paths returned to VSCode on Windows.

view details

Vadim Chugunov

commit sha ecffa9d27123f8366a4f758af280ce3d261c34f0

Implement cancellation.

view details

push time in 13 days

pull request commentvadimcn/vscode-lldb

Fix adaptor failing to find libpython on Linux

Sorry, this patch has been obsoleted by bundling Python in v1.6

pcpthm

comment created time in 13 days

created tagvadimcn/vscode-lldb

tagv1.6.0

A native debugger extension for VSCode based on LLDB

created time in 14 days

delete tag vadimcn/vscode-lldb

delete tag : v1.6.0-dev.201009.2200

delete time in 14 days

created tagvadimcn/vscode-lldb

tagv1.6.0-dev.2010130059

A native debugger extension for VSCode based on LLDB

created time in 14 days

issue closedvadimcn/vscode-lldb

Swift debugging not able to display variable values, "unable to determine byte size

OS: <!-- including version --> VSCode version: <!-- from Help/About --> Extension version: <!-- from Extensions panel --> Toolchain version: <!-- Name and version of the compiler you used. Run <compiler> --version for C++ or rustup show for Rust. --> Build target: <!-- Sometimes it's helpful to know the GNU/LLVM target "triple" you were building for, e.g. "x86_64-unknown-linux-gnu" --> Python version: <!-- Please provide for scripting-related issies. Run 'python3 -V' in VSCode terminal. -->

<!-- What is the problem and how did you get there -->

<!-- If reporting debugger crash or an internal error, please consider providing verbose log:

  1. Add "lldb.verboseLogging":true to your workspace configuration,
  2. Reproduce the problem,
  3. Paste debug output from Output/LLDB panel below. --> <details><summary>Debug log</summary><pre> <!-- Log goes here --> </pre></details>

closed time in 14 days

lourd

issue closedvadimcn/vscode-lldb

Support for Rust NDarray

OS: Windows 8.1 VSCode version: 1.49 Extension version: 0.2.313 Toolchain version: stable-x86_64-pc-windows-msvc Build target: stable-x86_64-pc-windows-msvc Python version:

I am building a rust application and it has lot of 1D and 2D NdArray. I wanted to visualise them in VSCode while debugging but it is showing only pointer. I see that you have a formatter/rust.py and you have defined visualisation for Rust types. I am not an expert in python (and rust as well), so don't know how to define this type. Can you provide some code hints on how to modify?
image

closed time in 14 days

selvavm

push eventvadimcn/vscode-lldb

Gabor Greif

commit sha 6b775c439992b6615e92f4938ee4e211f1b060cf

don't abbreviate commands as it can be confusing

view details

push time in 14 days

PR merged vadimcn/vscode-lldb

Don't abbreviate commands

as it can be confusing

+2 -2

0 comment

2 changed files

ggreif

pr closed time in 14 days

pull request commentvadimcn/vscode-lldb

A few touchups for BUILDING.md

thanks!

ggreif

comment created time in 14 days

push eventvadimcn/vscode-lldb

Gabor Greif

commit sha 9b655545d8a48b0ef7bbc653139149faca5e3ae7

Update BUILDING.md

view details

push time in 14 days

PR merged vadimcn/vscode-lldb

A few touchups for BUILDING.md
+2 -2

0 comment

1 changed file

ggreif

pr closed time in 14 days

issue commentvadimcn/vscode-lldb

`cargo-make` does not work with CodeLLDB

The "cargo" option exists for automatic extraction of build artifacts paths from the cargo output. It makes little sense to use it without "--message-format=json".

You should run cargo make via tasks.json (add "preLaunchTask" to launch configuration).

masnagam

comment created time in 15 days

issue commentvadimcn/vscode-lldb

AVG detects codelldb.exe as IDP.Generic

I think you should file this issue with AVG.

xire28

comment created time in 15 days

issue commentvadimcn/vscode-lldb

exceed fifty breakpoints lldb can't start

Can you please provide verbose log?

yyzhuxin

comment created time in 15 days

issue closedvadimcn/vscode-lldb

Can I remotely debug Android C/C++ code

I want to use LLDB to debug Android C/C++ code in VS Code

closed time in 15 days

chenls

issue commentvadimcn/vscode-lldb

not possible to use wt as external terminal

Codelldb defers to VSCode for launching new terminal windows. You should file this problem with them.

LuanVSO

comment created time in 15 days

issue commentvadimcn/vscode-lldb

Custom LLDB formatters not loading from the ~/.lldbinit file

@Rupemgera: That should work, and it does for me. Print output should appear in VSCode's Debug Console window.

mbargiel

comment created time in 15 days

issue commentvadimcn/vscode-lldb

Custom LLDB formatters not loading from the ~/.lldbinit file

@mbargiel: Yes, codelldb will not import ~/.lldbinit by default. If you'd like, you can achieve that, by adding to VSCode configuration: "lldb.launch.initCommands": ["command source ${env:HOME}/.lldbinit"]

mbargiel

comment created time in 15 days

delete tag vadimcn/vscode-lldb

delete tag : v1.2.0-alpha

delete time in 17 days

delete tag vadimcn/vscode-lldb

delete tag : v1.4.3-dev

delete time in 17 days

delete tag vadimcn/vscode-lldb

delete tag : v1.4.1-dev

delete time in 17 days

delete tag vadimcn/vscode-lldb

delete tag : v1.5.0-dev

delete time in 17 days

created tagvadimcn/vscode-lldb

tagv1.6.0-dev.201009.2200

A native debugger extension for VSCode based on LLDB

created time in 17 days

delete tag vadimcn/vscode-lldb

delete tag : v1.6.0-dev+201009.0414

delete time in 17 days

delete tag vadimcn/vscode-lldb

delete tag : v1.6.0-dev+201009.0122

delete time in 17 days

delete tag vadimcn/vscode-lldb

delete tag : v1.6.0-dev+200901.0353

delete time in 17 days

created tagvadimcn/vscode-lldb

tagv1.6.0-dev+201009.0414

A native debugger extension for VSCode based on LLDB

created time in 18 days

created tagvadimcn/vscode-lldb

tagv1.6.0-dev+201009.0122

A native debugger extension for VSCode based on LLDB

created time in 18 days

push eventvadimcn/build-tools

Vadim Chugunov

commit sha 21598605e3eea45ab4f017f18fbc501b5d6a76a3

LFS

view details

Vadim Chugunov

commit sha b3823266c85a6984f96742a209ca098a916329c9

sccache 0.2.13

view details

Vadim Chugunov

commit sha e76217880b66e028ef1808fec197105da8b0cdd1

Python 3.8

view details

push time in 19 days

push eventvadimcn/build-tools

Vadim Chugunov

commit sha 5cd38155bcd90de79c9815f6938d6f68ca9110f1

zstd v1.4.5

view details

push time in 19 days

push eventvadimcn/build-tools

Vadim Chugunov

commit sha 74f7e3817d1ffa99a50e3ff54c575631a3ee1b79

Track *.zst by LFS

view details

Vadim Chugunov

commit sha 980b18929edebf279319901b742e5a45a7dbf413

Python 3.8

view details

push time in 20 days

push eventvadimcn/build-tools

Vadim Chugunov

commit sha c5281e1834e2da9355405f08be3034ac229197b1

Track *.zst by LFS

view details

Vadim Chugunov

commit sha 85a2a14370a2f5af868e23e7bd7b4437cfd7df0f

Python 3.8

view details

push time in 20 days

push eventvadimcn/build-tools

Vadim Chugunov

commit sha 3d5619dbc9ae3e76f6ba218fd5911f1a797e7fbb

Track *.zst by LFS

view details

Vadim Chugunov

commit sha 7e1a5928bd1f6849f7ddb2b6002760c9adcfd157

Python 3.8

view details

push time in 20 days

issue openedindygreg/PyOxidizer

Ability to create a customized Python library for embedding into non-Rust apps.

Here's my scenario: I need to build a C++ application that expects to be linked to libpython (which it will use via the standard Py_... API). I want the app to be "xcopy-deployable" on Windows, Linux and Mac. Therefore, it must be entirely self-contained and have no dependencies on optional packages. One must also be careful to not depend on any host OS APIs that are "too new" and may not be present in older versions of the OS (looking at you, glibc >:-)

PyOxidizer solves a very similar problem, which is what drew my attention in this direction. However, as of now PyOxidizer cannot produce artifacts suitable for linking into non-Rust apps (at least not easily - I could probably scavenge what I need from intermediate build outputs).

It would be nice if there were a method for building the following from a configured PythonDistribution:

  • A directory tree containing /include and /lib directories (the latter containing libpython and any static libraries it depends upon). Bonus points for making it similar enough to a standard Python distro as to be compatible with CMake's FindPython module.
  • A directory tree containing resources to be deployed alongside the compiled app, including .pyc files, any shared libraries that Python runtime depends upon, etc. For my use-case, the ability to load Python modules/resources from memory is not required.

created time in 24 days

pull request commentindygreg/python-build-standalone

Add cross-builds for ARM

Debian Stretch might work as well; I went for Ubuntu Xenial just because it seemed to have a slightly lower version of glibc (2.23 vs 2.24). In the end, it seems to be not so important, as the lowest compatible version is determined by which glibc exports the program actually uses. Maybe you could save yourself the trouble of having to compile cross-toolchains...

vadimcn

comment created time in a month

pull request commentindygreg/python-build-standalone

Add cross-builds for ARM

Forgot another todo item:

  • I had to exclude _decimal from static modules, because it requires different compilation flags depending on the platform (use assembly on x86, pure C otherwise). This needs a better solution, unless you want to use C code on all platforms.
vadimcn

comment created time in a month

more