Re: [swift-users] بخصوص: About Swift Package Manager and LLDB

Interesting... You might want to add these discoveries to the SR that I mentioned, or file a new one with these comments. At this point you're trying to help out the folks working on SPM and a bug report is a more direct way to do that than the swift-users list. Jim > On Nov 7, 2017, at

Re: [swift-users] About Swift Package Manager and LLDB

It does look like this is a known bug (not yet fixed) in SPM: https://bugs.swift.org/browse/SR-3280 The bug isn’t fixed yet (apparently it’s blocked on a swift compiler issue.) There’s a workaround in that report, though I don’t know how viable it is.

Re: [swift-users] بخصوص: About Swift Package Manager and LLDB

> On Nov 6, 2017, at 2:21 PM, Jim Ingham via swift-users > <swift-users@swift.org> wrote: > > This works for me (with Xcode 9.0): > > > git clone https://github.com/PerfectlySoft/PerfectTemplate.git > <https://github.com/PerfectlySoft/PerfectTemplate.git>

Re: [swift-users] About Swift Package Manager and LLDB

Swift doesn’t seem to be reporting whatever the error is, I just see: ((SwiftASTContext*)0x7f8c555c84a0)->GetModule('PerfectTemplate') -- failed with no error That’s not very helpful. Again, I’ll probably need to make this happen locally to see what went wrong. If you have a project that

Re: [swift-users] About Swift Package Manager and LLDB

The log for “print self” was unfortunately captured too late. Reading in the PerfectTemplate module had already failed, and so any subsequent attempt will just report it as failed. To get the complete error log for this, you need to put: log enable -f /tmp/lldb-type-log.txt lldb types in

Re: [swift-users] LLDB fails when I update to Swift 3.1 (error in auto-import)

The lldb "types" log is the place where detailed info about what's going on gets dumped. Turn that on with: (lldb) log enable -f /tmp/lldb-types-log.txt lldb types Jim > On Apr 14, 2017, at 9:33 AM, Edward Connell via swift-users > wrote: > > Groan... I just tried to

Re: [swift-users] Debugger woes

> On Feb 3, 2017, at 6:55 AM, Maury Markowitz wrote: > >> On Jan 31, 2017, at 1:59 PM, Jim Ingham wrote: >> >> From the symptoms, it looks like the compiler is not holding onto >> "background" because it is no longer used. That's a desirable

Re: [swift-users] How to debug Segmentation Fault

There is a Linux port of lldb, the swift enabled version of which is included in the toolchains that are built for Swift on Linux. gdb will do fine for the C side of the world, but it knows nothing about Swift. So if you need to see the swift side of the world to understand your crash, you'll

Re: [swift-users] Debugger woes

From the symptoms, it looks like the compiler is not holding onto "background" because it is no longer used. That's a desirable thing to do for optimized code, but not at -O0. What happens if you rewrite this to: let background = sceneView.snapshot().cgImage!

Re: [swift-users] lldb not working when C module includes a header outside of it's /include dir

Could you put the working example in the bug as well? Jim > On Nov 10, 2016, at 11:39 AM, Andrey Fidrya via swift-users > wrote: > > Hi All, > > Update: I've found that debugging works if C module is in a separate > repository. So, this problem is only present if

Re: [swift-users] Swift REPL broken after updating to Sierra, is it just me?

There is a known bug in libedit's history file reader that can cause this crash. libedit is a system component that lldb uses to do command-line editing and the like. Try moving ~/.lldb-history to some other name, and then rerunning the REPL. If that works, can you attach that history file

Re: [swift-users] DWARF without DSYM

In any case where the .o files are temporary objects which the driver will delete when it's done, it has to generate a dSYM file before it deletes them. But if the .o files belong to the user it can assume it's okay to hold off on generating the dSYM. Same thing happens with the clang driver.

Re: [swift-users] Customizing my custom type's appearance in the debugger

The display in the variables view uses synthetic child providers: http://lldb.llvm.org/varformats.html We could hook up the Mirrors to the synthetic child providers if there is no formatter registered, but Mirrors always run code and we try not to run code for the variables view if we can