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

2017-11-07 Thread Jim Ingham via swift-users 
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 8:10 AM, ⁨‫Fadi Botros‬ ‫⁩ <⁨botros_f...@yahoo.com⁩> wrote:
> 
> Some information may be leading to resolve of this problem
> 
> I think "ld" tool does a lot of the trick
> 
> Notice the difference between the results of the two compilations (Xcode and 
> SPM):
> 
> Kitura example via Xcode, when invoked "target modules list" on lldb
> 
> Gets this
> [ 0] 788D7481-3E7E-3B4D-805E-A18937409552 0x0001 
> /Users/mac/Documen - Pastebin.com
> 
> [ 0] 788D7481-3E7E-3B4D-805E-A18937409552 0x0001 /Users/mac/Do...
> 
>  When invoked on the compiled via SPM it results in :
> [ 0] ED5DAA33-8E50-3EE9-8487-1C5931520130 0x0001 
> /Users/mac/Documen - Pastebin.com
> 
> [ 0] ED5DAA33-8E50-3EE9-8487-1C5931520130 0x0001 /Users/mac/Do...
> 
> 
> 
> It seems the modules are compiled and linked SEPARATELY in Xcode, and this 
> succeed in debugging
> But in SPM, all are compiled as one module (it may have submodules)
> 
> I think if you provide something compiles to dynamic link libraries on Linux 
> (and SPM in general) like frameworks on macOS, it will solve the problem
> 
> 
> Pastebin.com - #1 paste tool since 2002!
> Pastebin.com is the number one paste tool since 2002. Pastebin is a website 
> where you can store text online for ...
> 
> 
> 
> 
> من: Jim Ingham 
> إلى: ‫Fadi Botros‬ ‫  
> نسخة كربونية: Michael Gottesman ; 
> "swift-users@swift.org" 
> تاريخ الإرسال: الثلاثاء 7 نوفمبر، 2017‏ 2:29 ص
> الموضوع: 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.  
> Anyway, you can track that bug to see when this gets fixed.
> 
> Jim
> 
>> On Nov 6, 2017, at 3:45 PM, ⁨‫Fadi Botros‬ ‫⁩ <⁨botros_f...@yahoo.com⁩> 
>> wrote:
>> 
>> 
>> I don't think Perfect has problems because it debugs perfectly on Xcode
>> Kitura may have some flaws because on Xcode also causes some issues BUT YOU 
>> STILL CAN GET FRAME, ETC.. WHILE NOT HAVING THOSE IN SPM
>> 
>> The problem is in SPM
>> Just make the SPM build Swift Packages like Xcode (or equivalent)
>> 
>> من: Jim Ingham 
>> إلى: ‫Fadi Botros‬ ‫  
>> نسخة كربونية: Michael Gottesman ; 
>> "swift-users@swift.org" 
>> تاريخ الإرسال: الثلاثاء 7 نوفمبر، 2017‏ 1:39 ص
>> الموضوع: Re: بخصوص: بخصوص: [swift-users] About Swift Package Manager and LLDB
>> 
>> It isn’t quite as mysterious as that.  lldb emulates the context of the 
>> frame you are stopped in when you run “frame variable” or “expression”.  It 
>> looks like PerfectTemplate doesn’t have a problem, and doesn’t rely on 
>> modules that we can’t reconstruct.  But some of the other modules do have 
>> problems.  For instance, if I let the program come up, interrupt it and 
>> switch to a frame in the PerfectHTTPServer, then I see:
>> 
>> (lldb) expr let $mystr = "Some string"
>> error: in auto-import:
>> failed to get module 'PerfectHTTPServer' from AST context:
>> error: missing required modules: 'PerfectCHTTPParser', 'PerfectCZlib'
>> 
>> 
>> But that’s not the only one with problems, and I’m still not getting any 
>> useful error messages back from swift.  I’ll have to dig into this more.
>> 
>> Jim
>> 
>> 
>> 
>>> On Nov 6, 2017, at 2:38 PM, ⁨‫Fadi Botros‬ ‫⁩ <⁨botros_f...@yahoo.com⁩> 
>>> wrote:
>>> 
>>> WEIRD WEIRD WEIRD
>>> It seems it is threading issue
>>> Because when I tried to breakpoint on line 71 file main.swift (like you did)
>>> It worked perfectly
>>> I even could "frame variable" fully
>>> 
>>> It seems that perfect framework when handle an HTTP request, it makes 
>>> something in threads, I don't know how to debug it
>>> 
>>> Try to debug on line 31 then invoke an HTTP request on localhost:8181, you 
>>> will reproduce the error
>>> 
>>> But it works when I use xcode (Again this is irreleveant, this is not the 
>>> solution)
>>> 
>>> 
>>> من: Jim Ingham 
>>> إلى: ‫Fadi Botros‬ ‫  
>>> نسخة كربونية: Michael Gottesman ; 
>>> "swift-users@swift.org" 
>>> تاريخ الإرسال: الثلاثاء 7 نوفمبر، 2017‏ 12:21 ص
>>> الموضوع: Re: بخصوص: [swift-users] About Swift Package Manager and LLDB
>>> 
>>> This works for me (with Xcode 9.0):
>>> 
>>>  > git clone https://github.com/PerfectlySoft/PerfectTemplate.git PT
>>> Cloning into 'PT'...
>>> remote: Counting objects: 214, done.

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

2017-11-06 Thread Jim Ingham via swift-users 
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.  
Anyway, you can track that bug to see when this gets fixed.

Jim

> On Nov 6, 2017, at 3:45 PM, ⁨‫Fadi Botros‬ ‫⁩ <⁨botros_f...@yahoo.com⁩> wrote:
> 
> 
> I don't think Perfect has problems because it debugs perfectly on Xcode
> Kitura may have some flaws because on Xcode also causes some issues BUT YOU 
> STILL CAN GET FRAME, ETC.. WHILE NOT HAVING THOSE IN SPM
> 
> The problem is in SPM
> Just make the SPM build Swift Packages like Xcode (or equivalent)
> 
> من: Jim Ingham 
> إلى: ‫Fadi Botros‬ ‫  
> نسخة كربونية: Michael Gottesman ; 
> "swift-users@swift.org" 
> تاريخ الإرسال: الثلاثاء 7 نوفمبر، 2017‏ 1:39 ص
> الموضوع: Re: بخصوص: بخصوص: [swift-users] About Swift Package Manager and LLDB
> 
> It isn’t quite as mysterious as that.  lldb emulates the context of the frame 
> you are stopped in when you run “frame variable” or “expression”.  It looks 
> like PerfectTemplate doesn’t have a problem, and doesn’t rely on modules that 
> we can’t reconstruct.  But some of the other modules do have problems.  For 
> instance, if I let the program come up, interrupt it and switch to a frame in 
> the PerfectHTTPServer, then I see:
> 
> (lldb) expr let $mystr = "Some string"
> error: in auto-import:
> failed to get module 'PerfectHTTPServer' from AST context:
> error: missing required modules: 'PerfectCHTTPParser', 'PerfectCZlib'
> 
> 
> But that’s not the only one with problems, and I’m still not getting any 
> useful error messages back from swift.  I’ll have to dig into this more.
> 
> Jim
> 
> 
> 
>> On Nov 6, 2017, at 2:38 PM, ⁨‫Fadi Botros‬ ‫⁩ <⁨botros_f...@yahoo.com 
>> ⁩> wrote:
>> 
>> WEIRD WEIRD WEIRD
>> It seems it is threading issue
>> Because when I tried to breakpoint on line 71 file main.swift (like you did)
>> It worked perfectly
>> I even could "frame variable" fully
>> 
>> It seems that perfect framework when handle an HTTP request, it makes 
>> something in threads, I don't know how to debug it
>> 
>> Try to debug on line 31 then invoke an HTTP request on localhost:8181, you 
>> will reproduce the error
>> 
>> But it works when I use xcode (Again this is irreleveant, this is not the 
>> solution)
>> 
>> 
>> من: Jim Ingham >
>> إلى: ‫Fadi Botros‬ ‫ > 
>> نسخة كربونية: Michael Gottesman > >; "swift-users@swift.org 
>> " > >
>> تاريخ الإرسال: الثلاثاء 7 نوفمبر، 2017‏ 12:21 ص
>> الموضوع: Re: بخصوص: [swift-users] About Swift Package Manager and LLDB
>> 
>> This works for me (with Xcode 9.0):
>> 
>>  > git clone https://github.com/PerfectlySoft/PerfectTemplate.git 
>>  PT
>> Cloning into 'PT'...
>> remote: Counting objects: 214, done.
>> remote: Total 214 (delta 0), reused 0 (delta 0), pack-reused 214
>> Receiving objects: 100% (214/214), 48.65 KiB | 0 bytes/s, done.
>> Resolving deltas: 100% (110/110), done.
>>  > cd PT
>>  > swift build
>> 
>>  > cd .build/debug
>>  > lldb PerfectTemplate
>> (lldb) target create "PerfectTemplate"
>> Current executable set to 'PerfectTemplate' (x86_64).
>> (lldb) b s -l 71
>> Breakpoint 1: where = PerfectTemplate`main + 2627 at main.swift:71, address 
>> = 0x000100436c33
>> (lldb) run
>> Process 26948 launched: 
>> '/private/tmp/PT/.build/x86_64-apple-macosx10.10/debug/PerfectTemplate' 
>> (x86_64)
>> Process 26948 stopped
>> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
>> frame #0: 0x000100436c33 PerfectTemplate`main at main.swift:71
>>68
>>69do {
>>70// Launch the servers based on the configuration data.
>> -> 71try HTTPServer.launch(configurationData: confData)
>>  ^
>>72} catch {
>>73fatalError("\(error)") // fatal error launching one of 
>> the servers
>>74}
>> Target 0: (PerfectTemplate) stopped.
>> (lldb) expr confData.count
>> (Int) $R1 = 1
>> 
>> Do the same steps not work for you?  If you were doing something different 
>> can you describe the steps you took?
>> 
>> Jim
>> 
>>> On Nov 6, 2017, at 2:10 PM, ⁨‫Fadi Botros‬ ‫⁩ <⁨botros_f...@yahoo.com 
>>> ⁩> wrote:
>>> 
>>> Also please noted
>>> I think it is a SPM issue not an LLDB one
>>> Because when compiled on the same mac with Xcode (Swift package manager 
>>> generate Xcode project), then use xcode-build
>>> LLDB works

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

2017-11-06 Thread Jim Ingham via swift-users 


> 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> PT
> Cloning into 'PT'...
> remote: Counting objects: 214, done.
> remote: Total 214 (delta 0), reused 0 (delta 0), pack-reused 214
> Receiving objects: 100% (214/214), 48.65 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (110/110), done.
>  > cd PT
>  > swift build
> 
>  > cd .build/debug
>  > lldb PerfectTemplate
> (lldb) target create "PerfectTemplate"
> Current executable set to 'PerfectTemplate' (x86_64).
> (lldb) b s -l 71

You’ll have to say:

(lldb) br s -l 71 

here.

Jim

> Breakpoint 1: where = PerfectTemplate`main + 2627 at main.swift:71, address = 
> 0x000100436c33
> (lldb) run
> Process 26948 launched: 
> '/private/tmp/PT/.build/x86_64-apple-macosx10.10/debug/PerfectTemplate' 
> (x86_64)
> Process 26948 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
> frame #0: 0x000100436c33 PerfectTemplate`main at main.swift:71
>68 
>69 do {
>70 // Launch the servers based on the configuration data.
> -> 71 try HTTPServer.launch(configurationData: confData)
>   ^
>72 } catch {
>73 fatalError("\(error)") // fatal error launching one of 
> the servers
>74 }
> Target 0: (PerfectTemplate) stopped.
> (lldb) expr confData.count
> (Int) $R1 = 1
> 
> Do the same steps not work for you?  If you were doing something different 
> can you describe the steps you took?
> 
> Jim
> 
>> On Nov 6, 2017, at 2:10 PM, ⁨‫Fadi Botros‬ ‫⁩ <⁨botros_f...@yahoo.com 
>> <mailto:botros_f...@yahoo.com>⁩> wrote:
>> 
>> Also please noted
>> I think it is a SPM issue not an LLDB one
>> Because when compiled on the same mac with Xcode (Swift package manager 
>> generate Xcode project), then use xcode-build
>> LLDB works perfectly in this circumstances
>> 
>> I think you should refine the compilation script generated by SPM to 
>> generate something like Xcode results (I think Xcode itself uses normal 
>> Swift toolchain, I think it does nothing here more than generating a better 
>> compilation/linking script)
>> 
>> 
>> من: Jim Ingham <jing...@apple.com <mailto:jing...@apple.com>>
>> إلى: ‫Fadi Botros‬ ‫ <botros_f...@yahoo.com <mailto:botros_f...@yahoo.com>> 
>> نسخة كربونية: Michael Gottesman <mgottes...@apple.com 
>> <mailto:mgottes...@apple.com>>; "swift-users@swift.org 
>> <mailto:swift-users@swift.org>" <swift-users@swift.org 
>> <mailto:swift-users@swift.org>>
>> تاريخ الإرسال: الإثنين 6 نوفمبر، 2017‏ 11:45 م
>> الموضوع: 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 shows the issue 
>> which you can make available, please file a bug with a description of how 
>> you build and debug this app, I’ll take a look.
>> 
>> Jim
>> 
>> 
>>> On Nov 6, 2017, at 12:56 PM, ⁨‫Fadi Botros‬ ‫⁩ <⁨botros_f...@yahoo.com 
>>> <mailto:botros_f...@yahoo.com>⁩> wrote:
>>> 
>>> OK
>>> Here is when captured "print self" log from the beginning
>>> 
>>> Attached here is the full log file
>>> See the attachments
>>> من: Jim Ingham <jing...@apple.com <mailto:jing...@apple.com>>
>>> إلى: ‫Fadi Botros‬ ‫ <botros_f...@yahoo.com <mailto:botros_f...@yahoo.com>> 
>>> نسخة كربونية: Michael Gottesman <mgottes...@apple.com 
>>> <mailto:mgottes...@apple.com>>; "swift-users@swift.org 
>>> <mailto:swift-users@swift.org>" <swift-users@swift.org 
>>> <mailto:swift-users@swift.org>>
>>> تاريخ الإرسال: الإثنين 6 نوفمبر، 2017‏ 10:15 م
>>> الموضوع: 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

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

2017-11-06 Thread Jim Ingham via swift-users 
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 shows the issue which you 
can make available, please file a bug with a description of how you build and 
debug this app, I’ll take a look.

Jim


> On Nov 6, 2017, at 12:56 PM, ⁨‫Fadi Botros‬ ‫⁩ <⁨botros_f...@yahoo.com⁩> 
> wrote:
> 
> OK
> Here is when captured "print self" log from the beginning
> 
> Attached here is the full log file
> See the attachments
> من: Jim Ingham 
> إلى: ‫Fadi Botros‬ ‫  
> نسخة كربونية: Michael Gottesman ; 
> "swift-users@swift.org" 
> تاريخ الإرسال: الإثنين 6 نوفمبر، 2017‏ 10:15 م
> الموضوع: 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 your ~/.lldbinit file and then start a fresh debugging session and capture 
> the whole session.
> 
> The failure from the REPL  is because you have to tell the REPL where to look 
> for other frameworks from which it might load modules.  You can pass 
> appropriate -I, -L and -F flags to the “swift” invocation too tell the 
> compiler lldb’s using to implement the REPL where to look for this module.
> 
> The example you gave seems to be a MacOS X example.  The binary type was 
> MachO etc.  If this is just a small example that you are using to demonstrate 
> the problem, can you file a PR with the swift bug reporter with this example 
> and how you built/ran it and we can take a look here.  That’s probably easier 
> than trying to pass logs back and forth.
> 
> Jim
> 
>> On Nov 6, 2017, at 11:27 AM, ⁨‫Fadi Botros‬ ‫ via swift-users⁩ 
>> <⁨swift-users@swift.org ⁩> wrote:
>> 
>> This happens when try to print(self)
>> Processing command: po print(self) HandleCommand, cmd_obj : 'expression' 
>> Handl - Pastebin.com 
>> 
>> 
>> Processing command: po print(self) HandleCommand, cmd_obj : 'expressio...
>>  
>> 
>> 
>> This happens when REPL then try to "import PerfectTemplate"
>> == [UserExpression::Evaluate] Parsing expression import PerfectTemplate == 
>> Swif - Pastebin.com 
>> 
>> 
>> == [UserExpression::Evaluate] Parsing expression import PerfectTemplate == 
>> ...
>>  
>> 
>> 
>> Also the same problem happens in Kitura (even if only use packages that 
>> depend on Swift 4)
>> 
>> من: Michael Gottesman >
>> إلى: Michael Gottesman > 
>> نسخة كربونية: "swift-users@swift.org " 
>> >; ‫Fadi Botros‬ ‫ 
>> >
>> تاريخ الإرسال: الإثنين 6 نوفمبر، 2017‏ 7:01 م
>> الموضوع: Re: [swift-users] About Swift Package Manager and LLDB
>> 
>> Or actually:
>> 
>> https://github.com/apple/swift/blob/master/docs/DebuggingTheCompiler.rst#debugging-failures-in-lldb
>>  
>> 
>> 
>> I would just enable all of the logging and post it here or if the log is 
>> very big put the log into a pastebin.
>> 
>>> On Nov 6, 2017, at 8:59 AM, Michael Gottesman via swift-users 
>>> > wrote:
>>> 
>> 
>> I am not going to answer this fully (I forwarded it to the appropriate 
>> people though). But to help them out, can you go to 
>> ./docs/DebuggingTheCompiler and enable lldb logging and post the output here?
>> 
>> Michael
>> 
>>> On Nov 6, 2017, at 8:43 AM, ⁨‫Fadi Botros‬ ‫ via swift-users⁩ 
>>> <⁨swift-users@swift.org ⁩> wrote:
>>> 
>>> I'm interested in doing Web Application using Swift and promoting this to 
>>> be a trend someday.
>>> But I couldn't find a way to debug web apps without using Xcode
>>> This is irrelevant because web applications are mainly on Linux, so what if 
>>> we want to do remote debugging ?
>>> 
>>> I tried using the SPM, and when I try to compile a Kitura or Perfect app 
>>> then try to debug it, it gives me this
>>> 
>>> (lldb) po print(self)
>>> warning: Swift error in module .
>>> Debug info from this module will be unavailable in the debugger.
>>> 
>>> error: in auto-import:
>>> failed to get module '' from AST context
>>> 
>>> I'm using macOS Sierra (sorry didn't have time to upgrade), with

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

2017-11-06 Thread Jim Ingham via swift-users 
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 your ~/.lldbinit file and then start a fresh debugging session and capture 
the whole session.

The failure from the REPL  is because you have to tell the REPL where to look 
for other frameworks from which it might load modules.  You can pass 
appropriate -I, -L and -F flags to the “swift” invocation too tell the compiler 
lldb’s using to implement the REPL where to look for this module.

The example you gave seems to be a MacOS X example.  The binary type was MachO 
etc.  If this is just a small example that you are using to demonstrate the 
problem, can you file a PR with the swift bug reporter with this example and 
how you built/ran it and we can take a look here.  That’s probably easier than 
trying to pass logs back and forth.

Jim

> On Nov 6, 2017, at 11:27 AM, ⁨‫Fadi Botros‬ ‫ via swift-users⁩ 
> <⁨swift-users@swift.org⁩> wrote:
> 
> This happens when try to print(self)
> Processing command: po print(self) HandleCommand, cmd_obj : 'expression' 
> Handl - Pastebin.com 
> 
> 
> Processing command: po print(self) HandleCommand, cmd_obj : 'expressio...
>  
> 
> 
> This happens when REPL then try to "import PerfectTemplate"
> == [UserExpression::Evaluate] Parsing expression import PerfectTemplate == 
> Swif - Pastebin.com 
> 
> 
> == [UserExpression::Evaluate] Parsing expression import PerfectTemplate == ...
>  
> 
> 
> Also the same problem happens in Kitura (even if only use packages that 
> depend on Swift 4)
> 
> من: Michael Gottesman 
> إلى: Michael Gottesman  
> نسخة كربونية: "swift-users@swift.org" ; ‫Fadi Botros‬ 
> ‫ 
> تاريخ الإرسال: الإثنين 6 نوفمبر، 2017‏ 7:01 م
> الموضوع: Re: [swift-users] About Swift Package Manager and LLDB
> 
> Or actually:
> 
> https://github.com/apple/swift/blob/master/docs/DebuggingTheCompiler.rst#debugging-failures-in-lldb
>  
> 
> 
> I would just enable all of the logging and post it here or if the log is very 
> big put the log into a pastebin.
> 
>> On Nov 6, 2017, at 8:59 AM, Michael Gottesman via swift-users 
>> > wrote:
>> 
> 
> I am not going to answer this fully (I forwarded it to the appropriate people 
> though). But to help them out, can you go to ./docs/DebuggingTheCompiler and 
> enable lldb logging and post the output here?
> 
> Michael
> 
>> On Nov 6, 2017, at 8:43 AM, ⁨‫Fadi Botros‬ ‫ via swift-users⁩ 
>> <⁨swift-users@swift.org ⁩> wrote:
>> 
>> I'm interested in doing Web Application using Swift and promoting this to be 
>> a trend someday.
>> But I couldn't find a way to debug web apps without using Xcode
>> This is irrelevant because web applications are mainly on Linux, so what if 
>> we want to do remote debugging ?
>> 
>> I tried using the SPM, and when I try to compile a Kitura or Perfect app 
>> then try to debug it, it gives me this
>> 
>> (lldb) po print(self)
>> warning: Swift error in module .
>> Debug info from this module will be unavailable in the debugger.
>> 
>> error: in auto-import:
>> failed to get module '' from AST context
>> 
>> I'm using macOS Sierra (sorry didn't have time to upgrade), with Swift 4 
>> that comes with Xcode 9
>> Also tried the same experiment on Xubuntu using Swift 4 debian package 
>> provided on swift.org  itself
>> 
>> The only succeeded way is to generate an xcodeproj and compile it, this is 
>> irrelevant because it is only macOS, while servers are Linux.
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-users
> 
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

2017-04-14 Thread Jim Ingham via swift-users 
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 update to Swift 3.1 on ubuntu 16.04. Everything 
> builds fine, but when I try to debug I get the dreaded:
> 
> error in auto-import: failed to get module 'XYZ' from AST context
> 
> Everything built and debugged just fine with the previous Swift release.
> I assume LLDB is unhappy about either failing to find an import, or somehow 
> thinking there is a duplicate.
> 
> How do we get LLDB to disclose the reason that it's failing?
> 
> Thanks, Ed
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Debugger woes

2017-02-03 Thread Jim Ingham via swift-users 

> 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 thing to do 
>> for optimized code, but not at -O0.
>> 
>> What happens if you rewrite this to:
>> 
>>  let background = sceneView.snapshot().cgImage!
>>  let cropped = background.cropping(to: overlayView.frame)
>>  UIGraphicsBeginImageContextWithOptions(overlayView.frame.size, 
>> false, 1.0)
>>   print(background)
> 
> I've been battling H3N2 so I only got a chance to try this now. Indeed, the 
> 'background' variable is "alive" in this version, I assume because of the 
> print() that follows?

Yes, that's most likely right.

> 
> Should I file through the normal Apple Bug Reporter, or is there a better 
> mechanism for Swift-related issues?

The official word on that is:

https://swift.org/contributing/#reporting-bugs

Jim

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

2017-02-01 Thread Jim Ingham via swift-users 
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 need to use that 
lldb.  You use it in pretty much the same way as gdb, and there are tutorials 
for its use at:

http://lldb.llvm.org

Jim

> On Feb 1, 2017, at 5:26 PM, Jens Alfke via swift-users 
>  wrote:
> 
> 
>> On Feb 1, 2017, at 5:25 PM, I wrote:
>> 
>> gdb is no longer used on Mac (we have lldb instead), so further discussion 
>> of it would be off-topic here :)
> 
> Oops, never mind that … I didn’t notice this was swift-users and thought it 
> was one of the Apple mailing lists. *facepalm*
> 
> —Jens
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Debugger woes

2017-01-31 Thread Jim Ingham via swift-users 
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!
let cropped = background.cropping(to: overlayView.frame)
UIGraphicsBeginImageContextWithOptions(overlayView.frame.size, 
false, 1.0)
print(background)

When you step to the UIGraphics... line, are you still able to print the 
variable?  If so, that's quite likely what is going on, and it would be great 
if you could file a bug about this.

Jim



> On Jan 31, 2017, at 10:54 AM, Maury Markowitz via swift-users 
>  wrote:
> 
> I hope this is the right place to ask this:
> 
> I'm using Xcode Version 8.2.1 (8C1002) and I'm trying to find out what's 
> going wrong in my Swift3 app. Here's the code:
> 
>   let background = sceneView.snapshot().cgImage!
>   let cropped = background.cropping(to: overlayView.frame)
>   UIGraphicsBeginImageContextWithOptions(overlayView.frame.size, 
> false, 1.0)
> 
> I have a breakpoint on the first line. When it trips I F6 to the next line 
> and examine background:
> 
> (lldb) p background
> (CGImage) $R0 = 0x0001741d4370 {}
> Printing description of background:
> 
>   < (kCGColorSpaceICCBased; 
> kCGColorSpaceModelRGB; sRGB IEC61966-2.1)>
>   width = 640, height = 998, bpc = 8, bpp = 32, row bytes = 2560 
> 
> Now I hit F6 again and do the same thing:
> 
> (lldb) p background
> error: :3:1: error: use of unresolved identifier 'background'
> background
> ^~
> 
> This happens to pretty much every variable in the app, after running another 
> line or two, it apparently disappears. This is particularly annoying in this 
> case, because QuickLook fails almost every time, which makes debugging image 
> work somewhat difficult.
> 
> I've cleaned and rebooted and it keeps coming back. Any suggestions?
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

2016-11-10 Thread Jim Ingham via swift-users 
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 there are two modules in 
> Sources/ dir of the same repo. It doesn't matter if headers are located in 
> /usr/local/include or in other location.
> 
> Andrey
> 
> 
>> On 09 Nov 2016, at 22:48, Andrey Fidrya  wrote:
>> 
>> Hi All,
>> 
>> When C module includes a header outside of module's include/ directory and
>> not residing in /usr/local/include or /usr/include, lldb stops showing 
>> variable
>> values for the entire application.
>> 
>> I've created a ticket with a test project and additional details in the bug 
>> tracker,
>> any help is appreciated:
>> https://bugs.swift.org/browse/SR-3169
>> 
>> Andrey
>> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

2016-10-06 Thread Jim Ingham via swift-users 
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 to the Radar you mentioned, so we 
can make sure this is the same history reading bug?

Thanks,

Jim
 

> On Oct 6, 2016, at 12:46 PM, Jens Persson via swift-users 
>  wrote:
> 
> I've filed radar 28657007 and attached the two crashlogs that is generated 
> (one for lldb, and one for repl_swift.
> /Jens
> 
> On Thu, Oct 6, 2016 at 9:25 PM, Jens Persson  wrote:
> Here is with Xcode.app:
> 
> › sudo xcode-select -s /Applications/Xcode.app
> Password:
> › 
> › swift -v
> Apple Swift version 3.0 (swiftlang-800.0.46.2 clang-800.0.38)
> Target: x86_64-apple-macosx10.9
> /Applications/Xcode.app/Contents/Developer/usr/bin/lldb "--repl=-target 
> x86_64-apple-macosx10.9 -enable-objc-interop -sdk 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
>  -color-diagnostics"
> Welcome to Apple Swift version 3.0 (swiftlang-800.0.46.2 clang-800.0.38). 
> Type :help for assistance.
> Segmentation fault: 11
> 
> /Jens
> 
> 
> On Thu, Oct 6, 2016 at 9:23 PM, Jens Persson  wrote:
> I was trying both Xcode and Xcode-beta, I just happened to copy paste while 
> Xcode-beta was selected ... Anyway, both of them crash like that.
> /Jens
> 
> 
> On Thu, Oct 6, 2016 at 7:22 PM, Kate Stone  wrote:
> If you’ve specified “sudo xcode-select -s /Applications/Xcode.app” then it’s 
> surprising that the REPL session is attempting to use the LLDB and SDK from 
> /Applications/Xcode-beta.app.  Can you double-check what “xcode-select -p” 
> reports?
> 
> I can’t say I’ve seen a segmentation fault on REPL launch.  If you see the 
> same behavior once moving to the GM build of Xcode it would definitely be 
> worth filing a radar via bugreport.apple.com with an LLDB crashlog attached 
> to investigate further.
> 
> Kate Stone k8st...@apple.com
>  Xcode Low Level Tools
> 
>> On Oct 6, 2016, at 6:51 AM, Jens Persson via swift-users 
>>  wrote:
>> 
>> After updating to Sierra I can no longer use the Swift REPL. It crashes 
>> immediately (see Terminal session below). Anyone else having the same 
>> problem, any workaround?
>> 
>> It didn't help to download and reinstall the command line tools for 10.12. 
>> 
>> (I had Xcode 8 and 8.1 beta installed before updating to Sierra. It might 
>> have happened just after I did a sudo xcode-select -s 
>> /Applications/Xcode.app )
>> 
>> See Terminal session below.
>> 
>> /Jens
>> 
>> 
>> › swift
>> Welcome to Apple Swift version 3.0 (swiftlang-800.0.48 clang-800.0.40). Type 
>> :help for assistance.
>> Segmentation fault: 11
>> › 
>> › swift -v
>> Apple Swift version 3.0 (swiftlang-800.0.49 clang-800.0.40)
>> Target: x86_64-apple-macosx10.9
>> /Applications/Xcode-beta.app/Contents/Developer/usr/bin/lldb "--repl=-target 
>> x86_64-apple-macosx10.9 -enable-objc-interop -sdk 
>> /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
>>  -color-diagnostics"
>> Welcome to Apple Swift version 3.0 (swiftlang-800.0.48 clang-800.0.40). Type 
>> :help for assistance.
>> Segmentation fault: 11
>> › 
>> › 
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift
>>  -sdk 
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
>>  -target x86_64-apple-macosx10.12
>> Welcome to Apple Swift version 3.0 (swiftlang-800.0.46.2 clang-800.0.38). 
>> Type :help for assistance.
>> Segmentation fault: 11
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> 
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] DWARF without DSYM

2016-08-26 Thread Jim Ingham via swift-users 
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.

Jim

> On Aug 26, 2016, at 2:43 PM, Dmitry Shevchenko  wrote:
> 
> Ah I see, the dsym job is only created when the driver will also link the 
> final product, in Xcode build case, it separates the linking step.
> 
> On Fri, Aug 26, 2016 at 5:35 PM Dmitry Shevchenko  wrote:
> I experimented in Xcode, and with DWARF w/o dSYM selected, debugging still 
> works. And even though -g option is passed to swiftc, there's no dSYM 
> generation occurring. So besides -g, what else makes swiftc issues that 
> dsymutil call?
> 
> On Fri, Aug 26, 2016 at 3:37 PM Jim Ingham  wrote:
> dsymutil is only given the .o files and the executable - same thing lldb 
> sees.  So if it can find the module map to copy it into the dSYM, lldb can 
> find it and load it without the dSYM.  So whether it does work or not, it 
> should be able to.
> 
> Jim
> 
> > On Aug 26, 2016, at 11:37 AM, Jordan Rose via swift-users 
> >  wrote:
> >
> > I suppose it can, but in theory the module that goes into the dSYM wouldn't 
> > be the same as the one that gets used by clients of a library. (Example: 
> > the one in the dSYM needs to have info about private types.) Sean can 
> > probably explain better than I can.
> >
> > Jordan
> >
> >
> >> On Aug 26, 2016, at 9:36, Dmitry Shevchenko  wrote:
> >>
> >> I see. I thought LLDB can import modules independently of sources, isn't 
> >> that what target.swift-module-search-paths option is for?
> >>
> >> On Thu, Aug 25, 2016 at 4:15 PM Jordan Rose  wrote:
> >> Plain DWARF isn't sufficient to debug a Swift program (we actually stuff 
> >> the entire swiftmodule into the dSYM), but if you just want to trace 
> >> execution you should be able to use -gline-tables-only.
> >>
> >> Jordan
> >>
> >>
> >> > On Aug 25, 2016, at 13:10, Dmitry Shevchenko via swift-users 
> >> >  wrote:
> >> >
> >> > Can swiftc generate debug info without a separate dSYM bundle? -g option 
> >> > looks to always generate a dSYM.
> >> > ___
> >> > swift-users mailing list
> >> > swift-users@swift.org
> >> > https://lists.swift.org/mailman/listinfo/swift-users
> >>
> >
> > ___
> > swift-users mailing list
> > swift-users@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-users
> 

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

2016-06-26 Thread Jim Ingham via swift-users 
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 avoid it as it slows down debugging more than 
somewhat.

Jim


> On Jun 26, 2016, at 5:03 PM, Tim Vermeulen via swift-users 
>  wrote:
> 
> I already did that, sorry for not providing any code. Take this as an example:
> 
> public struct Wrapper {
> 
> private var elements: [Element]
> 
> public init(_ sequence: 
> S) {
> elements = [Element](sequence)
> }
> 
> }
> 
> extension Wrapper: Collection {
> 
> public var startIndex: Int { return elements.startIndex }
> public var endIndex: Int { return elements.endIndex }
> 
> public func index(after index: Int) -> Int {
> return index + 1
> }
> 
> public subscript(position: Int) -> Element {
> return elements[position]
> }
> 
> }
> 
> extension Wrapper: CustomReflectable {
> 
> public var customMirror: Mirror {
> return Mirror(self, unlabeledChildren: self, displayStyle: 
> .collection)
> }
> 
> }
> 
> If I debug an instance of this Wrapper type, then Xcode’s Variables View will 
> show
> 
> ▿ wrapper
>   ▿ elements = x values
> [0] = 0
> [1] = …
> 
> But the `elements` property is an implementation detail. What I would really 
> want to see is this:
> 
> ▿ wrapper = x values
>   [0] = 0
>   [1] = …
> 
> But I’m not sure if this is even possible. That’s basically why I’m asking 
> this. Hopefully it’s clearer now :)
> 
> One last thing to note, the code `dump(wrapper)` will print
> 
> ▿ 3 elements
>   - 1
>   - 2
>   - 3
> 
> to the console, which is good. If I don’t implement CustomReflectable, then 
> `dump(wrapper)` will show this:
> 
> ▿ Wrapper
>   ▿ elements: 3 elements
> - 1
> - 2
> - 3
> 
> So my CustomReflectable conformance is definitely doing something, but I 
> would like to see the results in the variables view as well.
> 
>> On 27 Jun 2016, at 01:40, Dmitri Gribenko > > wrote:
>> 
>> On Fri, Jun 24, 2016 at 3:53 PM, Tim Vermeulen via swift-users
>> > wrote:
>>> I’ve implemented a linked list. Now I’d like to be able to view the 
>>> elements of a linked list in the debugger just like with an array. In the 
>>> debugger, an array is represented like this:
>>> 
>>> [0] = the first element
>>> [1] = the second element
>>> etc
>>> 
>>> I wonder if I can do the same for my linked list. I already implemented 
>>> CustomReflectable, so the code `dump(myLinkedList)` shows this in the 
>>> console:
>>> 
>>> 3 elements
>>>  - first element
>>>  - second elements
>>>  - third element
>>> 
>>> I thought this would also change the appearance of my linked list in the 
>>> debugger, but unfortunately it’s unchanged. Is there a way to do what I’m 
>>> trying to do?
>> 
>> Try setting "displayStyle: .collection" when you call the Mirror initializer.
>> 
>> Dmitri
>> 
>> -- 
>> main(i,j){for(i=2;;i++){for(j=2;j> (j){printf("%d\n",i);}}} /*Dmitri Gribenko > >*/
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users