Re: [swift-users] Workarounds for SR-6039?

[Michael Gottesman via swift-users]

> On Jan 8, 2018, at 11:02 AM, Marc Palmer via swift-users 
>  wrote:
> 
> Hi,
> 
> It’s hard to be 100% certain because of bugs.swift.org being down currently, 
> but I believe I have hit this bug:

Just an FYI, I think it is back up now (it is for me). Did you just try?

+CC swift-infrastructure.

> 
> https://bugs.swift.org/browse/SR-6039 "A `protocol A: class` is not any 
> `AnyObject`”
> 
> This is marked as a duplicate of a presumably very old issue judging by its 
> low number:
> 
> https://bugs.swift.org/browse/SR-55 "non-@objc protocol existentials do not 
> conform to their own protocol type"
> 
> So, I have a protocol:
> 
> public protocol ActionAuditorObserver: AnyObject {
>func actionAuditorInserted(entries: [ActionAuditEntry])
> }
> 
> …where ActionAuditEntry is a struct.
> 
> Trying to use a generic collection of my own for these, of the form:
> 
> class ObserverSet {
> …
> }
> 
> Using:
> 
> let observers = ObserverSet()
> 
> …results in "'ActionAuditorObserver' is not convertible to ‘AnyObject’”.
> 
> I think this is indeed SR-6039, which makes me really sad as it implies this 
> is not going to be fixed imminently.
> 
> I am trying to write this as a pure-swift framework as so far have succeeded. 
> If I add @objc to the protocol as a workaround for this, I then can no longer 
> have the observer pass in an array of structs.
> 
> So then I have to change the struct to a class, and I’m pushed farther away 
> from my goals :(
> 
> Is there anything I am missing, or a better way to workaround this?
> 
> I have to have the ObserverSet require AnyObject because it needs to do 
> identity checking when removing them. Equatable does not make sense for 
> observers. Losing the struct and forcing @objc feels like such a bitter pill 
> for something so simple.
> 
> Thanks in advance
> Marc
> 
> ___
> 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] Compile error trying to follow Swift for Windows MSVC instructions

[Michael Gottesman via swift-users]

+CC Compnerd

> On Nov 9, 2017, at 10:36 AM, Eric Wing via swift-users 
>  wrote:
> 
> I'm trying to build Swift for Windows with Visual Studio using the
> directions found here:
> https://github.com/apple/swift/blob/master/docs/Windows.md
> 
> I'm following the MSVC section for directions. I am stuck in step 6.
> LLVM/Clang/Compiler-RT
> 
> I seem to be hitting a C++ error in the code in IndexDataStore.h. Any
> ideas on how to get around this?
> 
> 
> C:\PROGRA~2\MICROS~1\2017\COMMUN~1\VC\Tools\MSVC\1411~1.255\bin\Hostx64\x64\cl.exe
> /nologo /TP -DGTEST_HAS_RTTI=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE
> -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE
> -D_CRT_SECURE_NO_WARNINGS -D_GNU_SOURCE -D_HAS_EXCEPTIONS=0
> -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -Itools\clang\lib\Index -IC:\Source\SWIFT\llvm\tools\clang\lib\Index
> -IC:\Source\SWIFT\llvm\tools\clang\include -Itools\clang\include
> -Iinclude -IC:\Source\SWIFT\llvm\include /DWIN32 /D_WINDOWS
> /Zc:inline /Zc:strictStrings /Oi /Zc:rvalueCast /W4 -wd4141 -wd4146
> -wd4180 -wd4244 -wd4258 -wd4267 -wd4291 -wd4345 -wd4351 -wd4355
> -wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4800
> -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702 -wd4245
> -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204
> -wd4577 -wd4091 -wd4592 -wd4319 -wd4324 -w14062 -we4238 /MD /O1 /Ob1
> -UNDEBUG  /EHs-c- /GR- /showIncludes
> /Fotools\clang\lib\Index\CMakeFiles\clangIndex.dir\IndexDataStore.cpp.obj
> /Fdtools\clang\lib\Index\CMakeFiles\clangIndex.dir\clangIndex.pdb /FS
> -c C:\Source\SWIFT\llvm\tools\clang\lib\Index\IndexDataStore.cpp
> C:\Source\SWIFT\llvm\tools\clang\include\clang/Index/IndexDataStore.h(41):
> error C3646: 'ModTime': unknown override specifier
> C:\Source\SWIFT\llvm\tools\clang\include\clang/Index/IndexDataStore.h(41):
> error C4430: missing type specifier - int assumed. Note: C++ does not
> support default-int
> C:\Source\SWIFT\llvm\tools\clang\include\clang/Index/IndexDataStore.h(74):
> error C3646: 'ModTime': unknown override specifier
> C:\Source\SWIFT\llvm\tools\clang\include\clang/Index/IndexDataStore.h(74):
> error C4430: missing type specifier - int assumed. Note: C++ does not
> support default-int
> C:\Source\SWIFT\llvm\tools\clang\lib\Index\IndexDataStore.cpp(164):
> error C2039: 'ModTime': is not a member of
> 'clang::index::AbstractDirectoryWatcher::Event'
> C:\Source\SWIFT\llvm\tools\clang\include\clang/Index/IndexDataStore.h(38):
> note: see declaration of
> 'clang::index::AbstractDirectoryWatcher::Event'
> C:\Source\SWIFT\llvm\tools\clang\lib\Index\IndexDataStore.cpp(164):
> error C2039: '__this': is not a member of
> 'clang::index::AbstractDirectoryWatcher::Event'
> C:\Source\SWIFT\llvm\tools\clang\include\clang/Index/IndexDataStore.h(38):
> note: see declaration of
> 'clang::index::AbstractDirectoryWatcher::Event'
> [2723/3603] Building CXX object
> tools\clang\lib\Index\CMakeFiles\clangIndex.dir\IndexingContext.cpp.obj
> ninja: build stopped: subcommand failed.
> 
> 
> Note: I'm using VS2017 instead of VS2015 because it's supposed to have
> better C++ conformance.
> 
> I also want to note, building Debug hits a different fatal error where
> MSVC aborts saying you must compile with /bigobj because the files are
> too large. I changed my build and then hit the above compile error
> with IndexDataStore.h. I then tried building a release version without
> /bigobj, but I hit the same compile error with IndexDataStore.h.
> 
> 
> 
> 
> 
> Also, can somebody clarify what the differences are between the
> different build approaches in the document (clang vs. MSVC vs.
> clang-cl). Will these all produce binaries that are interoperable with
> each other and allow me to link against regular MSVC built C
> libraries? And do one of these clang options need MSVC's clang-C2?
> 
> And also, what is Compiler-RT and since it is optional, what do I lose
> if I skip it?
> 
> And finally, why is the Win10 SDK needed? Doesn't that mean it won't
> work on Win7 or Win8? What could Swift need that requires Win10 APIs?
> 
> Thanks,
> Eric
> ___
> 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] بخصوص: About Swift Package Manager and LLDB

[Michael Gottesman via swift-users]

ally 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 mailto:jing...@apple.com>>
>>>>> إلى: ‫Fadi Botros‬ ‫ >>>> <mailto:botros_f...@yahoo.com>> 
>>>>> نسخة كربونية: Michael Gottesman >>>> <mailto:mgottes...@apple.com>>; "swift-users@swift.org 
>>>>> <mailto: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 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 <mailto:swift-users@swift.org>⁩> wrote:
>>>>>> 
>>>>>> This happens when try to print(self)
>>>>>> Processing command: po print(self) HandleCommand, cmd_obj : 'expression' 
>>>>>> Handl - Pastebin.com <https://pastebin.com/15b52C1x>
>>>>>> 
>>>>>> 
>>>>>> Processing command: po print(self) HandleCommand, cmd_obj : 'expressio...
>>>>>>  <https://pastebin.com/15b52C1x>
>>>>>> 
>>>>>> 
>>>>>> This happens when REPL then try to "import PerfectTemplate"
>>>>>> == [UserExpression::Evaluate] Parsing expression import PerfectTemplate 
>>>>>> == Swif - Pastebin.com <https://pastebin.com/FsGgXa54>
>>>>>> 
>>>>>> 
>>>>>> == [UserExpression::Evaluate] Parsing expression import PerfectTemplate 
>>>>>> == ...
>>>>>>  <https://pastebin.com/FsGgXa54>
>>>>>> 
>>>>>> 
>>>>>> Also the same problem happens in Kitura (even if only use packages that 
>>>>>> depend on Swift 4)
>>>>>> 
>>>>>> من: Michael Gottesman >>>>> <mailto:mgottes...@apple.com>>
>>>>>> إلى: Michael Gottesman >>>>> <mailto:mgottes...@apple.com>> 
>>>>>> نسخة كربونية: "swift-users@swift.org <mailto:swift-users@swift.org>" 
>>>>>> mailto:swift-users@swift.org>>; ‫Fadi Botros‬ ‫ 
>>>>>> mailto:botros_f...@yahoo.com>>
>>>>>> تاريخ الإرسال: الإثنين 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
>>>>>>  
>>>>>> <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 
>>>>>>> mailto:swift-users@swift.org>> 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 <mailto: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 <http://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 <mailto:swift-users@swift.org>
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-users>
>>>>>> 
>>>>>> ___
>>>>>> swift-users mailing list
>>>>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>>>>> <https://lists.swift.org/mailman/listinfo/swift-users>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ___
>>>>>> swift-users mailing list
>>>>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>>>>> <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] About Swift Package Manager and LLDB

[Michael Gottesman via swift-users]

Perfect! This is exactly what I was looking for. = ). Thanks!

> On Nov 6, 2017, at 11:27 AM, ⁨‫Fadi Botros‬ ‫⁩ <⁨botros_f...@yahoo.com⁩> 
> wrote:
> 
> This happens when try to print(self)
> Processing command: po print(self) HandleCommand, cmd_obj : 'expression' 
> Handl - Pastebin.com <https://pastebin.com/15b52C1x>
> 
> 
> Processing command: po print(self) HandleCommand, cmd_obj : 'expressio...
>  <https://pastebin.com/15b52C1x>
> 
> 
> This happens when REPL then try to "import PerfectTemplate"
> == [UserExpression::Evaluate] Parsing expression import PerfectTemplate == 
> Swif - Pastebin.com <https://pastebin.com/FsGgXa54>
> 
> 
> == [UserExpression::Evaluate] Parsing expression import PerfectTemplate == ...
>  <https://pastebin.com/FsGgXa54>
> 
> 
> 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
>  
> <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 
>> mailto:swift-users@swift.org>> 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 <mailto: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 <http://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 <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> <https://lists.swift.org/mailman/listinfo/swift-users>
> 
> ___
> swift-users mailing list
> swift-users@swift.org <mailto: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] About Swift Package Manager and LLDB

[Michael Gottesman via swift-users]

Or actually:

https://github.com/apple/swift/blob/master/docs/DebuggingTheCompiler.rst#debugging-failures-in-lldb
 
<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 <mailto: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 <http://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 <mailto: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] About Swift Package Manager and LLDB

[Michael Gottesman via swift-users]

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

Re: [swift-users] Swift 4.0 LLDBFrontend Crash

[Michael Gottesman via swift-users]

I just added a section to ./docs/DebuggingTheCompiler.rst on how to get enable 
logging from LLDB.

Can you enable the logging there and add file an SR?

Michael

> On Oct 7, 2017, at 11:27 AM, Edward Connell  wrote:
> 
> Hi Michael,
> No I am not evaluating an expression or anything. This all worked fine in 
> past builds.
> 
> I simply set a breakpoint in a function and after stopping while gathering 
> values for the debugger view, it crashes.
> 
> It doesn't crash in all functions, but it does crash when trying to stop in 
> many different functions.
> An example function signature where it crashes is (DataView is a concrete 
> struct):
> 
> public func setupForward(mode: EvaluationMode, inData: DataView, labels: 
> DataView?,
>outData: inout DataView, backData: 
> inout DataView?) throws { ... }
> 
> Before calling the function, all of the parameters have valid values that I 
> can examine. But as soon as I step into this function, LLDB crashes with that 
> message. It behaves the same way with other functions that have different 
> signatures.
> 
> I tried to create a very simple repro case using this signature, but it 
> didn't crash. My project is on GitHub and this can be easily reproduced. The 
> only pain is installing my project on your test machine.
> 
> Ubuntu 16.04
> Swift 4.0 release
> NVidia gpu
> Netlib https://github.com/ewconnell/Netlib/wiki#installation 
> 
> CLion IDE with Swift plugin
> 
> 1) do a debug build
> 2) set a breakpoint at CudaSoftmax.swift:44  or any line in the function
> 3) run
> 4) when it stops LLDBFrontend crashes
> 
> LLDBFrontend: 
> /home/buildnode/jenkins/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/swift/lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp:613:
>  (anonymous namespace)::SourceAccess (anonymous 
> namespace)::AccessEnforcementSelection::getSourceAccess(swift::SILValue): 
> Assertion `isa(address) || isa(address)' failed.
> Stack dump:
> 0.While running pass #10 SILModuleTransform ""Access Enforcement 
> Selection"".
> 
> 
> Using the LLDB CLI I am able to stop there. If I try "fr var -O" with 
> mode, inData, and labels, it prints their values no problem
> outData and backData gives me a segmentation violation
> The visible difference is the "inout"
> 
> Not sure what the problem is. It worked fine in the past.
> 
> If you can think of an experiment I can try to create a simple repro case, 
> please let me know.
> 
> Thanks, Ed
> 
> On Fri, Oct 6, 2017 at 4:34 PM, Michael Gottesman  > wrote:
> It looks like this is failing during guaranteed optimization. Are you running 
> an expression in the debugger and we are crashing there?
> 
> Michael
> 
>> On Oct 6, 2017, at 11:53 AM, Edward Connell via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> While trying to debug a Netlib function, LLDB is crashing
>> 
>> I'm not sure what this assert means.
>> 
>> LLDBFrontend: 
>> /home/buildnode/jenkins/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/swift/lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp:613:
>>  (anonymous namespace)::SourceAccess (anonymous 
>> namespace)::AccessEnforcementSelection::getSourceAccess(swift::SILValue): 
>> Assertion `isa(address) || isa(address)' failed.
>> Stack dump:
>> 0.   While running pass #10 SILModuleTransform ""Access Enforcement 
>> Selection"".
>> 
>> It fails every time and the same way in several functions, but not all 
>> functions.
>> I tried to create a simple repro with the same function signature, but I 
>> can't get the simple case to fail.
>> A debug build isn't doing whole-module-optimization, so that's not it
>> 
>> Ideas anyone?
>> 
>> Who owns the LLDBFrontend?
>> 
>> 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] Swift 4.0 LLDBFrontend Crash

[Michael Gottesman via swift-users]

It looks like this is failing during guaranteed optimization. Are you running 
an expression in the debugger and we are crashing there?

Michael

> On Oct 6, 2017, at 11:53 AM, Edward Connell via swift-users 
>  wrote:
> 
> While trying to debug a Netlib function, LLDB is crashing
> 
> I'm not sure what this assert means.
> 
> LLDBFrontend: 
> /home/buildnode/jenkins/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/swift/lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp:613:
>  (anonymous namespace)::SourceAccess (anonymous 
> namespace)::AccessEnforcementSelection::getSourceAccess(swift::SILValue): 
> Assertion `isa(address) || isa(address)' failed.
> Stack dump:
> 0.While running pass #10 SILModuleTransform ""Access Enforcement 
> Selection"".
> 
> It fails every time and the same way in several functions, but not all 
> functions.
> I tried to create a simple repro with the same function signature, but I 
> can't get the simple case to fail.
> A debug build isn't doing whole-module-optimization, so that's not it
> 
> Ideas anyone?
> 
> Who owns the LLDBFrontend?
> 
> 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] Why no new Development Snapshots since Aug 3?

[Michael Gottesman via swift-users]

This is a question for Mishal (+CC).

> On Aug 10, 2017, at 6:42 PM, Jens Persson via swift-users 
>  wrote:
> 
> The most recent Development Snapshot is 2017-08-03, but it used to be a new 
> one almost daily. What happened?
> /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] Annotating C APIs without changing the original header files

[Michael Gottesman via swift-users]

+Ankit

Michael

> On May 12, 2017, at 10:10 AM, Geordie J via swift-users 
>  wrote:
> 
> To continue this thread: I managed to annotate a bunch of C APIs with 
> modulename.apinotes. This works with Xcode (to a certain degree - pointers, 
> enums, and especially OpaquePointers are tricky). I’m now trying to build my 
> package with SwiftPM and it doesn’t seem to recognise the apinotes file. 
> 
> @Doug Gregor, would you be able to advise as to whether apinotes works with 
> SwiftPM (on Linux) and whether it requires some extra settings that I may be 
> unaware of?
> 
> Thanks and best regards for the weekend,
> Geordie
> 
> 
>> Am 08.05.2017 um 00:51 schrieb Geordie Jay > >:
>> 
>> I'm having the same issue. The renames seem to work, as in they disappear 
>> from the global scope with a fixit to rename to the new (namespaced) version 
>> if I type in the name manually, but they don't appear as static members of 
>> the enum type, regardless of how I call them. Would appreciate some help 
>> with this too.
>> 
>> Cheers,
>> Geordie 
>> Rick Mann mailto:rm...@latencyzero.com>> schrieb am 
>> So. 7. Mai 2017 um 23:06:
>> I'm trying to use apinotes for this third-party C library (call it 
>> "Lib.dylib"). It has an enum lgs_error_t:
>> 
>> typedef enum {
>> lgs_error_none = 0,
>> lgs_error_invalid_handle = -1,
>> lgs_error_null = -2,
>> lgs_error_invalid_parameter = -3,
>> lgs_error_invalid_operation = -4,
>> lgs_error_queue_full = -5
>> } lgs_error_t;
>> 
>> So I wrote apinotes ("Lib.apinotes") that look like this, next to the 
>> .dylib, and part of my Xcode iOS app target:
>> 
>> Enumerators:
>> # lgs_error_t
>> 
>> - Name: lgs_error_none
>>   SwiftName: lgs_error_t.none
>> - Name: lgs_error_invalid_handle
>>   SwiftName: lgs_error_t.invalidHandle
>> - Name: lgs_error_null
>>   SwiftName: lgs_error_t.nullParameter
>> - Name: lgs_error_invalid_parameter
>>   SwiftName: lgs_error_t.invalideParameter
>> - Name: lgs_error_invalid_operation
>>   SwiftName: lgs_error_t.invalidOperation
>> - Name: lgs_error_queue_full
>>   SwiftName: lgs_error_t.queueFull
>> 
>> But this line of code fails:
>> 
>> var err: lgs_error_t = .nullParameter
>> Type 'lgs_error_t' has no member 'nullParameter'
>> 
>> Am I missing something else?
>> 
>> > On May 4, 2017, at 16:55 , Douglas Gregor via swift-users 
>> > mailto:swift-users@swift.org>> wrote:
>> >
>> >
>> >> On May 3, 2017, at 4:10 PM, Geordie J via swift-users 
>> >> mailto:swift-users@swift.org>> wrote:
>> >>
>> >> Hi everyone,
>> >>
>> >> I’m about to start on another big project with Swift on Android and would 
>> >> like to annotate that JNI headers as much as possible before I do: 
>> >> specifically I’d like to make _Nonnull and CF_SWIFT_NAME annotations to 
>> >> the headers found in a user's jni.h.
>> >>
>> >> The question is: is it possible to annotate headers this without changing 
>> >> the original header files? Specifically I’m looking for an options that 
>> >> allows annotations in a separate file, probably one that is read when 
>> >> loading the package’s module.modulemap.
>> >>
>> >> I’d like to distribute the annotations in a SwiftPM package that also 
>> >> exposes the original (hopefully annotated) headers. Up until now I’ve 
>> >> been using Swift to override methods in code, but this isn’t as clean or 
>> >> extensible and I fear it may have other (particularly performance) 
>> >> implications.
>> >>
>> >> I guess the alternative would be to just maintain and distribute a 
>> >> modified version of jni.h with the annotations, but that would be a "last 
>> >> resort” option.
>> >
>> >
>> > This is the role of API notes, which you can see here:
>> >
>> >   https://github.com/apple/swift/tree/master/apinotes 
>> > 
>> >
>> > with some rough documentation-in-source here:
>> >
>> >   
>> > https://github.com/apple/swift-clang/blob/stable/lib/APINotes/APINotesYAMLCompiler.cpp
>> >  
>> > 
>> >
>> >   - Doug
>> >
>> > ___
>> > swift-users mailing list
>> > swift-users@swift.org 
>> > https://lists.swift.org/mailman/listinfo/swift-users 
>> > 
>> 
>> 
>> --
>> Rick Mann
>> rm...@latencyzero.com 
>> 
>> 
> 
> ___
> 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] Help! Slicing an array is very expensive

[Michael Gottesman via swift-users]

Could you file a bug report? bugs.swift.org?

Michael

> On May 9, 2017, at 12:59 AM, Howard Lovatt via swift-users 
>  wrote:
> 
> My mistake. If I create a new array I get the problem. EG:
> 
> import Foundation
> 
> func elapsed(s: DispatchTime, e: DispatchTime) -> Double {
> return Double(e.uptimeNanoseconds - s.uptimeNanoseconds) / 1_000_000_000
> }
> 
> let s = 250_000_000
> var a = [UInt8]()
> a.reserveCapacity(s)
> 
> let sa = DispatchTime.now()
> for i in 1 ... s {
> a.append(0)
> }
> let ea = DispatchTime.now()
> print("Append time: \(elapsed(s: sa, e: ea)) s")
> 
> let st = DispatchTime.now()
> a = Array(a[0 ..< (s >> 1)])
> let et = DispatchTime.now()
> print("Trim time: \(elapsed(s: st, e: et)) s")
> print("a count: \(a.count), capacity: \(a.capacity)")
> 
> 
> Prints:
> 
> Append time: 2.65726525 s
> Trim time: 36.954417356 s
> a count: 12500, capacity: 125001696
> 
>   -- Howard.
> 
> On 9 May 2017 at 17:53, Howard Lovatt  > wrote:
> I find trimming relative to appending OK on my 6 year old MacBook Pro. EG:
> 
> import Foundation
> 
> func elapsed(s: DispatchTime, e: DispatchTime) -> Double {
> return Double(e.uptimeNanoseconds - s.uptimeNanoseconds) / 1_000_000_000
> }
> 
> let s = 250_000_000
> var a = [UInt8]()
> a.reserveCapacity(s)
> 
> let sa = DispatchTime.now()
> for i in 1 ... s {
> a.append(0)
> }
> let ea = DispatchTime.now()
> print("Append time: \(elapsed(s: sa, e: ea)) s")
> 
> let st = DispatchTime.now()
> let ha = a[0 ..< (s >> 1)]
> let et = DispatchTime.now()
> print("Trim time: \(elapsed(s: st, e: et)) s")
> 
> print("ha count: \(ha.count), capacity: \(ha.capacity)")
> 
> 
> Prints:
> 
> Append time: 2.612397389 s
> Trim time: 0.000444132 s
> ha count: 12500, capacity: 12500
> 
>   -- Howard.
> 
> On 9 May 2017 at 12:56, Kelvin Ma via swift-users  > wrote:
> Depending on what you’re trying to do with the data, you might be better off 
> using an UnsafeBufferPointer and allocating and reallocating that, C-style.
> 
> On Mon, May 8, 2017 at 7:01 PM, Philippe Hausler via swift-users 
> mailto:swift-users@swift.org>> wrote:
> I wonder if Data might be a better tool for the job here since it is it’s own 
> slice type and would avoid copying large amounts of data into temporary 
> buffers.
> 
> > On May 8, 2017, at 16:47, Rick Mann via swift-users  > > wrote:
> >
> > I have this C library that interacts with some hardware over the network 
> > that produces a ton of data. It tells me up front the maximum size the data 
> > might be so I can allocate a buffer for it, then does a bunch of network 
> > requests downloading that data into the buffer, then tells me when it's 
> > done and what the final, smaller size is.
> >
> > Thanks to previous discussions on the list, I settled on using a [UInt8] as 
> > the buffer, because it let me avoid various .withUnsafePointer{} calls (I 
> > need the unsafe buffer pointer to live outside the scope of the closures). 
> > Unfortunately, When I go to shrink the buffer to its final size with:
> >
> >self.dataBuffer = Array(self.dataBuffer![0 ..< finalBufferSize])
> >
> > This ends up taking over 2 minutes to complete (on an iPad Pro). 
> > finalBufferSize is very large, 240 MB, but I think it's doing a very naive 
> > copy.
> >
> > I've since worked around this problem, but is there any way to improve on 
> > this?
> >
> > Thanks,
> >
> > --
> > Rick Mann
> > rm...@latencyzero.com 
> >
> >
> > ___
> > 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

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

Re: [swift-users] How to Debug: Swift 3.1 Optimizations Causes All Sorts of Memory Crashes on My Apps

[Michael Gottesman via swift-users]

> On Apr 5, 2017, at 3:13 PM, Felipe Cypriano via swift-users 
>  wrote:
> 
> Hello,
> 
> We have updated our codebase to Xcode 8.3 and to my knowledge that means we 
> are now using Swift 3.1 compiler. Our first release using it - almost no 
> change to code since we release very often - had a huge increase in crashes 
> related to memory all over the codebase. The solution was to turn off all 
> Swift optimizations. This forum thread is related to the problem: 
> https://forums.developer.apple.com/message/219236#219236 
> 
> 
> I have never debugged an compiler related problem so I'm looking into advice 
> on how to pin point what the problem really is. Why our code works with 
> -Onone but crashes with both -O and -Owholemodule? Any tips would be 
> appreciated.

So this is happening with just -O (i.e. no whole module). In that case I would 
do this. Take the main command line that you are passing to swiftc and add the 
option -###. This causes the driver to dump the subcommands that it is going to 
run. So for instance if I have the following command line:

   xcrun swiftc test.swift  test2.swift main.swift  -module-name Test -O  -###

I get the following output:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift
 -frontend -c -primary-file test.swift test2.swift main.swift -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 -O -module-name Test -o 
/var/folders/z0/zl5mqfcj25db895ldcgpzdxmgn/T/test-00eef5.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift
 -frontend -c test.swift -primary-file test2.swift main.swift -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 -O -module-name Test -o 
/var/folders/z0/zl5mqfcj25db895ldcgpzdxmgn/T/test2-a29a57.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift
 -frontend -c test.swift test2.swift -primary-file main.swift -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 -O -module-name Test -o 
/var/folders/z0/zl5mqfcj25db895ldcgpzdxmgn/T/main-bfcad6.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
 /var/folders/z0/zl5mqfcj25db895ldcgpzdxmgn/T/test-00eef5.o 
/var/folders/z0/zl5mqfcj25db895ldcgpzdxmgn/T/test2-a29a57.o 
/var/folders/z0/zl5mqfcj25db895ldcgpzdxmgn/T/main-bfcad6.o -force_load 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/arc/libarclite_macosx.a
 -framework CoreFoundation -syslibroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
 -lobjc -lSystem -arch x86_64 -L 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx
 -rpath 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx
 -macosx_version_min 10.9.0 -no_objc_category_merging -o Test

Notice how the -O is on each line. This is the flag that ensures that 
optimizations are being run. To disable optimizations on a specific swift file, 
you can add to the -c line the flag:

  -disable-sil-perf-optzns

This will disable sil performance optimizations while ensuring that everything 
else is exactly as if one is running with optimizations enabled.

Then I would create a little script that takes in these command lines and puts 
-disable-sil-perf-optzns on all such .o command lines except for 1. This will 
then allow you to figure out which specific compilation invocation is causing 
the miscompile.

Why don't you try that and respond back if it works for you?

Michael

> 
> Thanks,
> Felipe Cypriano
> ___
> 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] Unable to build swift master branch

[Michael Gottesman via swift-users]

> On Apr 2, 2017, at 1:17 PM, Mohit Athwani  wrote:
> 
> Hi Michael,
> 
> I just submitted my pull request: 
> https://github.com/apple/swift-corelibs-foundation/pull/928 
> <https://github.com/apple/swift-corelibs-foundation/pull/928>
> Now waiting for an admin to initiate tests.
> 
> Thanks so much for your help!

HTH!

Michael

> 
> Cheers!
> Mohit
> 
> On Sun, Apr 2, 2017 at 12:36 PM, Michael Gottesman  <mailto:mgottes...@apple.com>> wrote:
> No worries. Just trying to be helpful = ).
> 
> Michael
> 
>> On Apr 2, 2017, at 12:27 PM, Mohit Athwani > <mailto:mohit.athw...@gmail.com>> wrote:
>> 
>> Hi Michael,
>> 
>> Thanks for checking up on me. I'm actually working on it right now. Will 
>> give you an update in an hour or so...
>> 
>> Cheers!
>> 
>> 
>> --
>> Mohit Athwani
>> http://about.me/mohitathwani <http://about.me/mohitathwani>
>> 
>> On Apr 2, 2017, 12:59 AM -0700, Michael Gottesman > <mailto:mgottes...@apple.com>>, wrote:
>>> Hey Mohit!
>>> 
>>> Were you able to build successfully?
>>> 
>>> Michael
>>> 
>>>> On Mar 30, 2017, at 4:29 PM, Michael Gottesman >>> <mailto:mgottes...@apple.com>> wrote:
>>>> 
>>>> I was just informed that swift-corelibs-foundation is actually using 
>>>> ninja! My bad!
>>>> 
>>>> Still I would use the preset from the bots. It should just work. 
>>>> Otherwise, you are missing a dependency or have differing versions/etc.
>>>> 
>>>> Michael
>>>> 
>>>>> On Mar 30, 2017, at 4:25 PM, Michael Gottesman >>>> <mailto:mgottes...@apple.com>> wrote:
>>>>> 
>>>>>> 
>>>>>> On Mar 30, 2017, at 4:22 PM, Michael Gottesman via swift-users 
>>>>>> mailto:swift-users@swift.org>> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> On Mar 30, 2017, at 12:31 PM, Mohit Athwani via swift-users 
>>>>>>> mailto:swift-users@swift.org>> wrote:
>>>>>>> 
>>>>>>> I'm trying to get back to work starting from scratch on Swift 
>>>>>>> Foundation on my Ubuntu 16.04 LTS system.
>>>>>>> 
>>>>>>> I cloned the main swift repo and all of it's dependencies via ssh
>>>>>>> ./swift/utils/update-checkout --clone-with-ssh
>>>>>>> and after running (taken from instructions from the Foundation site):
>>>>>>> 
>>>>>>> swift/utils/build-script --xctest --foundation -t
>>>>>>> 
>>>>>>> I get the following error:
>>>>>>> 
>>>>>>> + make build-tests
>>>>>>> /bin/bash ../libtool  --tag=CC   --mode=link 
>>>>>>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>>>>>>>  -Wall -Wno-deprecated-declarations  -fblocks 
>>>>>>> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>>>>>>>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY   -g -O0 -rpath 
>>>>>>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>>>>>>>   -o dispatch_apply dispatch_apply.o libbsdtests.la 
>>>>>>> <http://libbsdtests.la/> ../src/libdispatch.la <http://libdispatch.la/> 
>>>>>>>  -lbsd 
>>>>>>> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>>>>>>>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread 
>>>>>>> libtool: link: 
>>>>>>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>>>>>>>  -Wall -Wno-deprecated-declarations -fblocks 
>>>>>>> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>>>>>>>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY -g -O0 -o 
>>>>>>> .libs/dispatch_apply dispatch_apply.o  ./.libs/libbsdtests.a 
>>>>>>> ../src/.libs/libdispatch.so -lbsd 
>>>>>>> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>>>>>>>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread -Wl,-rpath 
&g

Re: [swift-users] Unable to build swift master branch

[Michael Gottesman via swift-users]

No worries. Just trying to be helpful = ).

Michael

> On Apr 2, 2017, at 12:27 PM, Mohit Athwani  wrote:
> 
> Hi Michael,
> 
> Thanks for checking up on me. I'm actually working on it right now. Will give 
> you an update in an hour or so...
> 
> Cheers!
> 
> 
> --
> Mohit Athwani
> http://about.me/mohitathwani
> 
> On Apr 2, 2017, 12:59 AM -0700, Michael Gottesman , 
> wrote:
>> Hey Mohit!
>> 
>> Were you able to build successfully?
>> 
>> Michael
>> 
>>> On Mar 30, 2017, at 4:29 PM, Michael Gottesman >> <mailto:mgottes...@apple.com>> wrote:
>>> 
>>> I was just informed that swift-corelibs-foundation is actually using ninja! 
>>> My bad!
>>> 
>>> Still I would use the preset from the bots. It should just work. Otherwise, 
>>> you are missing a dependency or have differing versions/etc.
>>> 
>>> Michael
>>> 
>>>> On Mar 30, 2017, at 4:25 PM, Michael Gottesman >>> <mailto:mgottes...@apple.com>> wrote:
>>>> 
>>>>> 
>>>>> On Mar 30, 2017, at 4:22 PM, Michael Gottesman via swift-users 
>>>>> mailto:swift-users@swift.org>> wrote:
>>>>> 
>>>>>> 
>>>>>> On Mar 30, 2017, at 12:31 PM, Mohit Athwani via swift-users 
>>>>>> mailto:swift-users@swift.org>> wrote:
>>>>>> 
>>>>>> I'm trying to get back to work starting from scratch on Swift Foundation 
>>>>>> on my Ubuntu 16.04 LTS system.
>>>>>> 
>>>>>> I cloned the main swift repo and all of it's dependencies via ssh
>>>>>> ./swift/utils/update-checkout --clone-with-ssh
>>>>>> and after running (taken from instructions from the Foundation site):
>>>>>> 
>>>>>> swift/utils/build-script --xctest --foundation -t
>>>>>> 
>>>>>> I get the following error:
>>>>>> 
>>>>>> + make build-tests
>>>>>> /bin/bash ../libtool  --tag=CC   --mode=link 
>>>>>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>>>>>>  -Wall -Wno-deprecated-declarations  -fblocks 
>>>>>> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>>>>>>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY   -g -O0 -rpath 
>>>>>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>>>>>>   -o dispatch_apply dispatch_apply.o libbsdtests.la 
>>>>>> <http://libbsdtests.la/> ../src/libdispatch.la <http://libdispatch.la/>  
>>>>>> -lbsd 
>>>>>> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>>>>>>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread 
>>>>>> libtool: link: 
>>>>>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>>>>>>  -Wall -Wno-deprecated-declarations -fblocks 
>>>>>> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>>>>>>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY -g -O0 -o 
>>>>>> .libs/dispatch_apply dispatch_apply.o  ./.libs/libbsdtests.a 
>>>>>> ../src/.libs/libdispatch.so -lbsd 
>>>>>> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>>>>>>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread -Wl,-rpath 
>>>>>> -Wl,//usr/lib/swift/linux -Wl,-rpath 
>>>>>> -Wl,/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>>>>>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64/libswiftCore.so:
>>>>>>  undefined reference to `objc_release'
>>>>>> clang-4.0: error: linker command failed with exit code 1 (use -v to see 
>>>>>> invocation)
>>>>>> Makefile:1123: recipe for target 'dispatch_apply' failed
>>>>>> make: *** [dispatch_apply] Error 1
>>>>>> swift/utils/build-script: fatal error: command terminated with a 
>>>>>> non-zero exit status 2, aborting
>>>>>> 
>>>>>> Looks like there is some undefined reference for objc_release in 
>>>>

Re: [swift-users] Unable to build swift master branch

[Michael Gottesman via swift-users]

Hey Mohit!

Were you able to build successfully?

Michael

> On Mar 30, 2017, at 4:29 PM, Michael Gottesman  wrote:
> 
> I was just informed that swift-corelibs-foundation is actually using ninja! 
> My bad!
> 
> Still I would use the preset from the bots. It should just work. Otherwise, 
> you are missing a dependency or have differing versions/etc.
> 
> Michael
> 
>> On Mar 30, 2017, at 4:25 PM, Michael Gottesman > <mailto:mgottes...@apple.com>> wrote:
>> 
>>> 
>>> On Mar 30, 2017, at 4:22 PM, Michael Gottesman via swift-users 
>>> mailto:swift-users@swift.org>> wrote:
>>> 
>>>> 
>>>> On Mar 30, 2017, at 12:31 PM, Mohit Athwani via swift-users 
>>>> mailto:swift-users@swift.org>> wrote:
>>>> 
>>>> I'm trying to get back to work starting from scratch on Swift Foundation 
>>>> on my Ubuntu 16.04 LTS system.
>>>> 
>>>> I cloned the main swift repo and all of it's dependencies via ssh
>>>> ./swift/utils/update-checkout --clone-with-ssh
>>>> and after running (taken from instructions from the Foundation site):
>>>> 
>>>> swift/utils/build-script --xctest --foundation -t
>>>> 
>>>> I get the following error:
>>>> 
>>>> + make build-tests
>>>> /bin/bash ../libtool  --tag=CC   --mode=link 
>>>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>>>>  -Wall -Wno-deprecated-declarations  -fblocks 
>>>> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>>>>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY   -g -O0 -rpath 
>>>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>>>>   -o dispatch_apply dispatch_apply.o libbsdtests.la 
>>>> <http://libbsdtests.la/> ../src/libdispatch.la <http://libdispatch.la/>  
>>>> -lbsd 
>>>> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>>>>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread 
>>>> libtool: link: 
>>>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>>>>  -Wall -Wno-deprecated-declarations -fblocks 
>>>> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>>>>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY -g -O0 -o .libs/dispatch_apply 
>>>> dispatch_apply.o  ./.libs/libbsdtests.a ../src/.libs/libdispatch.so -lbsd 
>>>> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>>>>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread -Wl,-rpath 
>>>> -Wl,//usr/lib/swift/linux -Wl,-rpath 
>>>> -Wl,/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>>>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64/libswiftCore.so:
>>>>  undefined reference to `objc_release'
>>>> clang-4.0: error: linker command failed with exit code 1 (use -v to see 
>>>> invocation)
>>>> Makefile:1123: recipe for target 'dispatch_apply' failed
>>>> make: *** [dispatch_apply] Error 1
>>>> swift/utils/build-script: fatal error: command terminated with a non-zero 
>>>> exit status 2, aborting
>>>> 
>>>> Looks like there is some undefined reference for objc_release in 
>>>> libswiftCore.
>>>> 
>>>> From the looks of the message it looks like swift was actually built but 
>>>> it's just that test cases weren't built. On this hunch, I went into my 
>>>> swift-corelibs-foundation folder and tried to execute:
>>>> 
>>>> ninja
>>>> 
>>>> Which tells me:
>>>> 
>>>> ninja: error: loading 'build.ninja': No such file or directory
>>> 
>>> swift-corelibs-foundation does not use ninja. I would use the build-script 
>>> line from the bots. That way you know you are doing the right thing.
>>> 
>>> Specifically:
>>> 
>>> URL: 
>>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/2413/consoleFull
>>>  
>>> <https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/2413/consoleFull>
>>> 
>>> Preset: buildbot_incremental_lin

Re: [swift-users] Unable to build swift master branch

[Michael Gottesman via swift-users]

I was just informed that swift-corelibs-foundation is actually using ninja! My 
bad!

Still I would use the preset from the bots. It should just work. Otherwise, you 
are missing a dependency or have differing versions/etc.

Michael

> On Mar 30, 2017, at 4:25 PM, Michael Gottesman  wrote:
> 
>> 
>> On Mar 30, 2017, at 4:22 PM, Michael Gottesman via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>>> 
>>> On Mar 30, 2017, at 12:31 PM, Mohit Athwani via swift-users 
>>> mailto:swift-users@swift.org>> wrote:
>>> 
>>> I'm trying to get back to work starting from scratch on Swift Foundation on 
>>> my Ubuntu 16.04 LTS system.
>>> 
>>> I cloned the main swift repo and all of it's dependencies via ssh
>>> ./swift/utils/update-checkout --clone-with-ssh
>>> and after running (taken from instructions from the Foundation site):
>>> 
>>> swift/utils/build-script --xctest --foundation -t
>>> 
>>> I get the following error:
>>> 
>>> + make build-tests
>>> /bin/bash ../libtool  --tag=CC   --mode=link 
>>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>>>  -Wall -Wno-deprecated-declarations  -fblocks 
>>> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>>>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY   -g -O0 -rpath 
>>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>>>   -o dispatch_apply dispatch_apply.o libbsdtests.la 
>>> <http://libbsdtests.la/> ../src/libdispatch.la <http://libdispatch.la/>  
>>> -lbsd 
>>> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>>>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread 
>>> libtool: link: 
>>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>>>  -Wall -Wno-deprecated-declarations -fblocks 
>>> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>>>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY -g -O0 -o .libs/dispatch_apply 
>>> dispatch_apply.o  ./.libs/libbsdtests.a ../src/.libs/libdispatch.so -lbsd 
>>> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>>>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread -Wl,-rpath 
>>> -Wl,//usr/lib/swift/linux -Wl,-rpath 
>>> -Wl,/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64/libswiftCore.so:
>>>  undefined reference to `objc_release'
>>> clang-4.0: error: linker command failed with exit code 1 (use -v to see 
>>> invocation)
>>> Makefile:1123: recipe for target 'dispatch_apply' failed
>>> make: *** [dispatch_apply] Error 1
>>> swift/utils/build-script: fatal error: command terminated with a non-zero 
>>> exit status 2, aborting
>>> 
>>> Looks like there is some undefined reference for objc_release in 
>>> libswiftCore.
>>> 
>>> From the looks of the message it looks like swift was actually built but 
>>> it's just that test cases weren't built. On this hunch, I went into my 
>>> swift-corelibs-foundation folder and tried to execute:
>>> 
>>> ninja
>>> 
>>> Which tells me:
>>> 
>>> ninja: error: loading 'build.ninja': No such file or directory
>> 
>> swift-corelibs-foundation does not use ninja. I would use the build-script 
>> line from the bots. That way you know you are doing the right thing.
>> 
>> Specifically:
>> 
>> URL: 
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/2413/consoleFull
>>  
>> <https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/2413/consoleFull>
>> 
>> Preset: buildbot_incremental_linux
>> 
>> If that does not work on your system, then something is misconfigured.
> 
> Let me elaborate, when I say misconfigured, I mean you are missing a 
> dependency.
> 
>> 
>> Also I wouldn't use --clone-with-ssh it is unnecessary.
>> 
>> 
>>> 
>>> Given my lack of experience here, I'm not quite sure how to go about 
>>> resolving these issues.
>>> 
>>> Could somebody help me out here please.
>>> 
>>> Thanks,
>>> 
>>> Mohit
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>> <https://lists.swift.org/mailman/listinfo/swift-users>
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> <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] Unable to build swift master branch

[Michael Gottesman via swift-users]

> On Mar 30, 2017, at 4:22 PM, Michael Gottesman via swift-users 
>  wrote:
> 
>> 
>> On Mar 30, 2017, at 12:31 PM, Mohit Athwani via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> I'm trying to get back to work starting from scratch on Swift Foundation on 
>> my Ubuntu 16.04 LTS system.
>> 
>> I cloned the main swift repo and all of it's dependencies via ssh
>> ./swift/utils/update-checkout --clone-with-ssh
>> and after running (taken from instructions from the Foundation site):
>> 
>> swift/utils/build-script --xctest --foundation -t
>> 
>> I get the following error:
>> 
>> + make build-tests
>> /bin/bash ../libtool  --tag=CC   --mode=link 
>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>>  -Wall -Wno-deprecated-declarations  -fblocks 
>> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY   -g -O0 -rpath 
>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>>   -o dispatch_apply dispatch_apply.o libbsdtests.la <http://libbsdtests.la/> 
>> ../src/libdispatch.la <http://libdispatch.la/>  -lbsd 
>> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread 
>> libtool: link: 
>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>>  -Wall -Wno-deprecated-declarations -fblocks 
>> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY -g -O0 -o .libs/dispatch_apply 
>> dispatch_apply.o  ./.libs/libbsdtests.a ../src/.libs/libdispatch.so -lbsd 
>> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread -Wl,-rpath 
>> -Wl,//usr/lib/swift/linux -Wl,-rpath 
>> -Wl,/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64/libswiftCore.so:
>>  undefined reference to `objc_release'
>> clang-4.0: error: linker command failed with exit code 1 (use -v to see 
>> invocation)
>> Makefile:1123: recipe for target 'dispatch_apply' failed
>> make: *** [dispatch_apply] Error 1
>> swift/utils/build-script: fatal error: command terminated with a non-zero 
>> exit status 2, aborting
>> 
>> Looks like there is some undefined reference for objc_release in 
>> libswiftCore.
>> 
>> From the looks of the message it looks like swift was actually built but 
>> it's just that test cases weren't built. On this hunch, I went into my 
>> swift-corelibs-foundation folder and tried to execute:
>> 
>> ninja
>> 
>> Which tells me:
>> 
>> ninja: error: loading 'build.ninja': No such file or directory
> 
> swift-corelibs-foundation does not use ninja. I would use the build-script 
> line from the bots. That way you know you are doing the right thing.
> 
> Specifically:
> 
> URL: 
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/2413/consoleFull
>  
> <https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/2413/consoleFull>
> 
> Preset: buildbot_incremental_linux
> 
> If that does not work on your system, then something is misconfigured.

Let me elaborate, when I say misconfigured, I mean you are missing a dependency.

> 
> Also I wouldn't use --clone-with-ssh it is unnecessary.
> 
> 
>> 
>> Given my lack of experience here, I'm not quite sure how to go about 
>> resolving these issues.
>> 
>> Could somebody help me out here please.
>> 
>> Thanks,
>> 
>> Mohit
>> ___
>> swift-users mailing list
>> swift-users@swift.org <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> ___
> swift-users mailing list
> swift-users@swift.org <mailto:swift-users@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-users 
> <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] Unable to build swift master branch

[Michael Gottesman via swift-users]

> On Mar 30, 2017, at 12:31 PM, Mohit Athwani via swift-users 
>  wrote:
> 
> I'm trying to get back to work starting from scratch on Swift Foundation on 
> my Ubuntu 16.04 LTS system.
> 
> I cloned the main swift repo and all of it's dependencies via ssh
> ./swift/utils/update-checkout --clone-with-ssh
> and after running (taken from instructions from the Foundation site):
> 
> swift/utils/build-script --xctest --foundation -t
> 
> I get the following error:
> 
> + make build-tests
> /bin/bash ../libtool  --tag=CC   --mode=link 
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>  -Wall -Wno-deprecated-declarations  -fblocks 
> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY   -g -O0 -rpath 
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>   -o dispatch_apply dispatch_apply.o libbsdtests.la  
> ../src/libdispatch.la   -lbsd 
> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread 
> libtool: link: 
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>  -Wall -Wno-deprecated-declarations -fblocks 
> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY -g -O0 -o .libs/dispatch_apply 
> dispatch_apply.o  ./.libs/libbsdtests.a ../src/.libs/libdispatch.so -lbsd 
> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread -Wl,-rpath 
> -Wl,//usr/lib/swift/linux -Wl,-rpath 
> -Wl,/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64/libswiftCore.so:
>  undefined reference to `objc_release'
> clang-4.0: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> Makefile:1123: recipe for target 'dispatch_apply' failed
> make: *** [dispatch_apply] Error 1
> swift/utils/build-script: fatal error: command terminated with a non-zero 
> exit status 2, aborting
> 
> Looks like there is some undefined reference for objc_release in libswiftCore.
> 
> From the looks of the message it looks like swift was actually built but it's 
> just that test cases weren't built. On this hunch, I went into my 
> swift-corelibs-foundation folder and tried to execute:
> 
> ninja
> 
> Which tells me:
> 
> ninja: error: loading 'build.ninja': No such file or directory

swift-corelibs-foundation does not use ninja. I would use the build-script line 
from the bots. That way you know you are doing the right thing.

Specifically:

URL: 
https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_04/2413/consoleFull

Preset: buildbot_incremental_linux

If that does not work on your system, then something is misconfigured.

Also I wouldn't use --clone-with-ssh it is unnecessary.


> 
> Given my lack of experience here, I'm not quite sure how to go about 
> resolving these issues.
> 
> Could somebody help me out here please.
> 
> Thanks,
> 
> Mohit
> ___
> 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-ci Response time

[Michael Gottesman via swift-users]

> On Mar 5, 2017, at 11:58 AM, Michael Gottesman  wrote:
> 
> 
>> On Mar 4, 2017, at 5:24 PM, Mohit Athwani via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> Hello,
>> 
>> I submitted my first pull request ever and I'm super excited!
>> 
>> @swift-ci has been tagged to test my code and I'm wondering how long does it 
>> take to perform it's tests and give me the result?
> 
> It depends on what type of test you trigger. There is documentation on the 
> swift-ci Continuous Integration system here: 
> https://github.com/apple/swift/blob/master/docs/ContinuousIntegration.md 
> . I 
> find that as long as not first in the day, the swift-ci system finishes a 
> smoke test in 30-40 minutes. If you are the first build of the day, the Linux 
> side can take a bit longer (IIRC the builders are wiped of artifacts nightly, 
> so the first build of the day is clean).
> 
> *NOTE* To trigger swift-ci you have to be a swift committer. If you look in 
> the README there is a link to the Contributing to Swift Guide. More 
> information is there.

Feel free to just mention in the PR that you need someone to trigger testing, 
any one of us will be more than happy to help = ).

Michael

> 
>> 
>> Thanks,
>> 
>> Mohit
>> ___
>> 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-ci Response time

[Michael Gottesman via swift-users]

> On Mar 4, 2017, at 5:24 PM, Mohit Athwani via swift-users 
>  wrote:
> 
> Hello,
> 
> I submitted my first pull request ever and I'm super excited!
> 
> @swift-ci has been tagged to test my code and I'm wondering how long does it 
> take to perform it's tests and give me the result?

It depends on what type of test you trigger. There is documentation on the 
swift-ci Continuous Integration system here: 
https://github.com/apple/swift/blob/master/docs/ContinuousIntegration.md 
. I 
find that as long as not first in the day, the swift-ci system finishes a smoke 
test in 30-40 minutes. If you are the first build of the day, the Linux side 
can take a bit longer (IIRC the builders are wiped of artifacts nightly, so the 
first build of the day is clean).

*NOTE* To trigger swift-ci you have to be a swift committer. If you look in the 
README there is a link to the Contributing to Swift Guide. More information is 
there.

> 
> Thanks,
> 
> Mohit
> ___
> 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] Getting started with development

[Michael Gottesman via swift-users]

> On Feb 13, 2017, at 7:09 PM, Mohit Athwani via swift-users 
>  wrote:
> 
> Hello,
> I'm a master's student in computer science and as part of my degree, I have 
> to contribute to some well known open source repositories. I have been an iOS 
> developer since 5 years now and I'm wondering if anybody in the community can 
> help me get started with where to look for issues/bugs and how to go about 
> fixing them and sending pull requests.

Is there a specific part of the compiler that interests you?

> 
> Appreciate help in any form!
> 
> Thanks,
> 
> Mohit
> ___
> 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] Importing Foundation or Glibc in REPL on Ubuntu 16.10 failing

[Michael Gottesman via swift-users]

Hmm... this sounds like this may be a good integration test. I am not sure what 
is going on here though. If I have a moment I will take a look a bit later 
today.

Michael

> On Jan 28, 2017, at 1:22 PM, Peter Ronnquist via swift-users 
>  wrote:
> 
> I have the same problem with importing Glibc into the REPL with "Swift
> 3.1 Development", Ubuntu 16.10, Jan 22, 2017, that was reported on the
> snapshot from 15 December (see below).
> 
> Is this working for anyone?
> 
> Best Regards
> Peter Ronnquist
> 
> 
> 
> 
> 
> On Monday 19 December Chris Double wrote:
> 
> 
> 
> Using the Ubuntu 16.10 snapshot from 15 December (or a build from
> master) I can't seem to get "import Foundation" or "import Glibc"
> working in the REPL. Here's an example:
> 
> -8<--
> $ swift
> Welcome to Swift version 3.1-dev (LLVM 7d4a331ed3, Clang d8c33dc710,
> Swift 2ea7951d05). Type :help for assistance.
>  1> import Glibc
> :3:10: note: in file included from :3:
> #include "///usr/include/utmp.h"
> ^
> 
> ///usr/include/utmp.h:23:10: note: in file included from
> ///usr/include/utmp.h:23:
> #include 
> ^
> 
> error: /usr/include/x86_64-linux-gnu/sys/types.h:146:10: error:
> 'stddef.h' file not found
> #include 
> ^
> 
> error: could not build Objective-C module 'SwiftGlibc'
> -8<--
> 
> 
> This works fine if I use 'swiftc' and compile a file:
> 
> $ cat x.swift
> import Glibc
> 
> print(random())
> 
> $ swiftc x.swift
> $ ./x
> ...
> -8<--
> 
> If I explicitly pass include paths to 'swift' it works in the REPL:
> 
> -8<--
> $ swift -I/home/user/swift-install/usr/lib/swift/clang/include/
> -I/home/user/swift-install/usr/include/lldb/Symbol/
> Welcome to Swift version 3.1-dev (LLVM 7d4a331ed3, Clang d8c33dc710,
> Swift 2ea7951d05). Type :help for assistance.
>  1> import Glibc
>  2> random()
> $R0: Int = 1804289383
> -8<--
> 
> Is there some setting or installation setup step I'm missing?
> 
> -- 
> http://bluishcoder.co.nz
> ___
> 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] Importing Foundation or Glibc in REPL on Ubuntu 16.10 failing

[Michael Gottesman via swift-users]

Peter, what are you doing specifically. I.e. are you passing any arguments to 
swift or something like that? Can you give a full reproducer?

Also can you type swift -v to confirm the version #?

Michael

> On Jan 30, 2017, at 12:04 PM, Michael Gottesman via swift-users 
>  wrote:
> 
> Interesting... it looks like we /do/ have an integration test that imports 
> glibc into the repl:
> 
> https://github.com/apple/swift-integration-tests/blob/master/repl/test-repl-glibc.py
>  
> <https://github.com/apple/swift-integration-tests/blob/master/repl/test-repl-glibc.py>
> 
> Probably could use one that imports Foundation though.
> 
> Michael
> 
> 
>> On Jan 30, 2017, at 12:00 PM, Michael Gottesman > <mailto:mgottes...@apple.com>> wrote:
>> 
>> Hmm... this sounds like this may be a good integration test. I am not sure 
>> what is going on here though. If I have a moment I will take a look a bit 
>> later today.
>> 
>> Michael
>> 
>>> On Jan 28, 2017, at 1:22 PM, Peter Ronnquist via swift-users 
>>> mailto:swift-users@swift.org>> wrote:
>>> 
>>> I have the same problem with importing Glibc into the REPL with "Swift
>>> 3.1 Development", Ubuntu 16.10, Jan 22, 2017, that was reported on the
>>> snapshot from 15 December (see below).
>>> 
>>> Is this working for anyone?
>>> 
>>> Best Regards
>>> Peter Ronnquist
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Monday 19 December Chris Double wrote:
>>> 
>>> 
>>> 
>>> Using the Ubuntu 16.10 snapshot from 15 December (or a build from
>>> master) I can't seem to get "import Foundation" or "import Glibc"
>>> working in the REPL. Here's an example:
>>> 
>>> -8<--
>>> $ swift
>>> Welcome to Swift version 3.1-dev (LLVM 7d4a331ed3, Clang d8c33dc710,
>>> Swift 2ea7951d05). Type :help for assistance.
>>> 1> import Glibc
>>> :3:10: note: in file included from :3:
>>> #include "///usr/include/utmp.h"
>>>^
>>> 
>>> ///usr/include/utmp.h:23:10: note: in file included from
>>> ///usr/include/utmp.h:23:
>>> #include 
>>>^
>>> 
>>> error: /usr/include/x86_64-linux-gnu/sys/types.h:146:10: error:
>>> 'stddef.h' file not found
>>> #include 
>>>^
>>> 
>>> error: could not build Objective-C module 'SwiftGlibc'
>>> -8<--
>>> 
>>> 
>>> This works fine if I use 'swiftc' and compile a file:
>>> 
>>> $ cat x.swift
>>> import Glibc
>>> 
>>> print(random())
>>> 
>>> $ swiftc x.swift
>>> $ ./x
>>> ...
>>> -8<--
>>> 
>>> If I explicitly pass include paths to 'swift' it works in the REPL:
>>> 
>>> -8<--
>>> $ swift -I/home/user/swift-install/usr/lib/swift/clang/include/
>>> -I/home/user/swift-install/usr/include/lldb/Symbol/
>>> Welcome to Swift version 3.1-dev (LLVM 7d4a331ed3, Clang d8c33dc710,
>>> Swift 2ea7951d05). Type :help for assistance.
>>> 1> import Glibc
>>> 2> random()
>>> $R0: Int = 1804289383
>>> -8<--
>>> 
>>> Is there some setting or installation setup step I'm missing?
>>> 
>>> -- 
>>> http://bluishcoder.co.nz <http://bluishcoder.co.nz/>
>>> ___
>>> 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] Importing Foundation or Glibc in REPL on Ubuntu 16.10 failing

[Michael Gottesman via swift-users]

Interesting... it looks like we /do/ have an integration test that imports 
glibc into the repl:

https://github.com/apple/swift-integration-tests/blob/master/repl/test-repl-glibc.py
 


Probably could use one that imports Foundation though.

Michael


> On Jan 30, 2017, at 12:00 PM, Michael Gottesman  wrote:
> 
> Hmm... this sounds like this may be a good integration test. I am not sure 
> what is going on here though. If I have a moment I will take a look a bit 
> later today.
> 
> Michael
> 
>> On Jan 28, 2017, at 1:22 PM, Peter Ronnquist via swift-users 
>>  wrote:
>> 
>> I have the same problem with importing Glibc into the REPL with "Swift
>> 3.1 Development", Ubuntu 16.10, Jan 22, 2017, that was reported on the
>> snapshot from 15 December (see below).
>> 
>> Is this working for anyone?
>> 
>> Best Regards
>> Peter Ronnquist
>> 
>> 
>> 
>> 
>> 
>> On Monday 19 December Chris Double wrote:
>> 
>> 
>> 
>> Using the Ubuntu 16.10 snapshot from 15 December (or a build from
>> master) I can't seem to get "import Foundation" or "import Glibc"
>> working in the REPL. Here's an example:
>> 
>> -8<--
>> $ swift
>> Welcome to Swift version 3.1-dev (LLVM 7d4a331ed3, Clang d8c33dc710,
>> Swift 2ea7951d05). Type :help for assistance.
>> 1> import Glibc
>> :3:10: note: in file included from :3:
>> #include "///usr/include/utmp.h"
>>^
>> 
>> ///usr/include/utmp.h:23:10: note: in file included from
>> ///usr/include/utmp.h:23:
>> #include 
>>^
>> 
>> error: /usr/include/x86_64-linux-gnu/sys/types.h:146:10: error:
>> 'stddef.h' file not found
>> #include 
>>^
>> 
>> error: could not build Objective-C module 'SwiftGlibc'
>> -8<--
>> 
>> 
>> This works fine if I use 'swiftc' and compile a file:
>> 
>> $ cat x.swift
>> import Glibc
>> 
>> print(random())
>> 
>> $ swiftc x.swift
>> $ ./x
>> ...
>> -8<--
>> 
>> If I explicitly pass include paths to 'swift' it works in the REPL:
>> 
>> -8<--
>> $ swift -I/home/user/swift-install/usr/lib/swift/clang/include/
>> -I/home/user/swift-install/usr/include/lldb/Symbol/
>> Welcome to Swift version 3.1-dev (LLVM 7d4a331ed3, Clang d8c33dc710,
>> Swift 2ea7951d05). Type :help for assistance.
>> 1> import Glibc
>> 2> random()
>> $R0: Int = 1804289383
>> -8<--
>> 
>> Is there some setting or installation setup step I'm missing?
>> 
>> -- 
>> http://bluishcoder.co.nz
>> ___
>> 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] question about swift and c callbacks

[Michael Gottesman via swift-users]

Can you create a quick tarball of the swiftpm project. Would expedite the 
answering of the question.

Michael

> On Dec 30, 2016, at 11:17 AM, Yang Yang via swift-users 
>  wrote:
> 
> I try to wrap a c library in swift package named Test.
> The code looks like this:
> 
> Test1.h
> 
> struct MyParams {
>   int (*func)();
> };
> 
> typedef struct MyParams MyParams;
> 
> Test2.h
> #include "Test1.h"
> 
> static int test(){
>   return 0;
> }
> 
> void myTest()
> {
>   MyParams params;
>   params.func = test;
> }
> 
> 
> Then I try to import the package into swift code and use
> in Test.swift.
> 
> import Test
> 
> class TestSwift {
>   func runtest(){
> myTest()
>   }
> }
> 
> However, the compiler report link error:
> function myTest: error: undefined reference to 'test'
> 
> If I comment out 
> "params.func = test;" in myTest.
> 
> It successfully build. How should I handle this situation?
> 
> Thanks,
> 
> Yang
> ___
> 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] Ubuntu 16.04 support?

[Michael Gottesman via swift-users]

+CC Todd.

> On Sep 20, 2016, at 9:25 PM, Ron Olson via swift-users 
>  wrote:
> 
> Hmm, I don’t get that at all:
> 
> Welcome to Swift version 3.0 (swift-3.0-RELEASE). Type :help for assistance.
> 1> import Foundation
> 2> NSURL(string:"http://swift.org"; )
> $R0: Foundation.NSURL? = 0x00427f00 {
> Foundation.NSObject = {}
> _base = {
> info = 7552
> pad = 0
> }
> _flags = 536887337
> _encoding = 0
> _string = 0x00427bd0 -> 0x7475d720 full type metadata for 
> Foundation.NSString + 16
> _baseURL = nil
> _extra = nil
> _resourceInfo = nil
> _range1 = {
> location = 0
> length = 4
> }
> _range2 = {
> location = 7
> length = 9
> }
> 
> … more of the same …
> 
> On 20 Sep 2016, at 22:28, Bouke Haarsma via swift-users wrote:
> 
> 
> On 2016-09-20 16:37:18 +, Lane Schwartz via swift-users said:
> 
> In addition to the installation instructions per swift.org, I also needed to 
> install "libpython2.7-dev". When starting the Swift REPL it threw the 
> following error;
> 
> ...swift/usr/bin/lldb: error while loading shared libraries: 
> libpython2.7.so.1.0: cannot open shared object file: No such file or directory
> 
> Installing that package resolved that issue. However the REPL loads, it 
> throws errors like this:
> 
> ubuntu-1604:~$ swift
> Welcome to Swift version 3.0 (swift-3.0-RELEASE). Type :help for assistance.
>   1> import Foundation
>   2> NSURL(string: "http://swift.org";)
> error: Couldn't lookup symbols:
>   type metadata accessor for Foundation.NSURL
>   Foundation.NSURL.__allocating_init (string : Swift.String) -> 
> Swift.Optional
> 
> I've downgraded to 14.04 LTS.
> 
> Thanks.
> 
> 
> On Tue, Sep 20, 2016 at 11:28 AM, Ron Olson via swift-users 
> mailto:swift-users@swift.org>> wrote:
> I downloaded the Ubuntu 15 release.
> 
> On 20 Sep 2016, at 11:26, Lane Schwartz wrote:
> 
> Thanks, Ron. Which binary release did you download? The ubuntu 15 release? Or 
> the 14 release?
> 
> On Tue, Sep 20, 2016 at 11:12 AM, Ron Olson via swift-users 
> mailto:swift-users@swift.org>> wrote:
> I can verify that the 3.0 Release works under 16; I downloaded it this 
> morning and it works fine.
> 
> 
> On 20 Sep 2016, at 11:10, Lane Schwartz via swift-users wrote:
> 
> I see that there are swift packages for Ubuntu 14 and 15, but not 16. Is
> Swift 3.0 known to work with Ubuntu 16? Can either of the aforementioned
> binary releases be used, or is compilation from source required?
> 
> Thanks,
> Lane
> ___
> 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 
> 
> 
> 
> 
> -- 
> When a place gets crowded enough to require ID's, social collapse is not
> far away.  It is time to go elsewhere.  The best thing about space travel
> is that it made it possible to go elsewhere.
> -- R.A. Heinlein, "Time Enough For Love"
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
> 
> 
> 
> 
> -- 
> When a place gets crowded enough to require ID's, social collapse is not
> far away.  It is time to go elsewhere.  The best thing about space travel
> is that it made it possible to go elsewhere.
> -- R.A. Heinlein, "Time Enough For Love"
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
> 
> 
> -- 
> -Bouke
> ___
> 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] libswiftCore.dylib was compiled with optimization - stepping may behave oddly;

[Michael Gottesman via swift-users]

If you are using the build-toolchain command, the stdlib will be built with 
optimizations enabled [as one would hope when you compile a toolchain = )].

If you want to have a debug stdlib, you need to make sure that the cmake flag 
-DSWIFT_STDLIB_BUILD_TYPE=Debug is set. (And probably you also want) 
-DSWIFT_STDLIB_ASSERTIONS=true.

Now you are not going to be able to get that from build-toolchain without 
modification. A few thoughts:

1. I would file a bug on bugs.swift.org saying that you want the ability to 
tell build-toolchain to build a debug standard library. I think that is a 
reasonable request. Please respond to this thread with the URL.
2. Notice that the build-toolchain script has a build-script invocation inside 
of it. There is an option to build-script called something along the lines of 
--expand-build-script-command-line perhaps? Look for expand in the --help. You 
can add that to the script to grab the internal build-script invocation. Then 
add to the end of that invocation the option: --debug-swift-stdlib 
--swift-stdlib-assertions. Keep in mind that this is just from memory so you 
may need to munge it a little bit.

Michael

> On Aug 26, 2016, at 12:36 AM, David Liu via swift-users 
>  wrote:
> 
> Hi all,  can any one here give me some pointers on debugging the standard 
> library?
> I may be compiling the toolchain incorrectly when i step through the code 
> variables on the stack frame are not available. 
> I think its due to this message when i start the REPL
> `libswiftCore.dylib was compiled with optimization - stepping may behave 
> oddly; variables may not be available.`
> I am using the /utils/build-toolchain command and did not touch the 
> presets.ini file.
> Any help is appreciated!
> 
> Thanks in advance
> 
> Dave
> 
> Process 13833 stopped
> * thread #1: tid = 0x3a6ffe, 0x0001000c3603 
> libswiftCore.dylib`ManagedBufferPointer.init(_uncheckedBufferClass : 
> AnyObject.Type, minimumCapacity : Int) -> ManagedBufferPointer 
> [inlined] Swift._roundUp (Swift.Int, toAlignment : Swift.Int) -> Swift.Int at 
> Builtin.swift:72, queue = 'com.apple.main-thread', stop reason = step in
> frame #0: 0x0001000c3603 
> libswiftCore.dylib`ManagedBufferPointer.init(_uncheckedBufferClass : 
> AnyObject.Type, minimumCapacity : Int) -> ManagedBufferPointer 
> [inlined] Swift._roundUp (Swift.Int, toAlignment : Swift.Int) -> Swift.Int at 
> Builtin.swift:72 [opt]
>69 @_versioned
>70 internal func _roundUp(_ offset: Int, toAlignment alignment: 
> Int) -> Int {
>71   _sanityCheck(offset >= 0)
> -> 72   return Int(_roundUpImpl(UInt(bitPattern: offset), 
> toAlignment: alignment))
>73 }
>74 
>75 // This function takes a raw pointer and returns a typed 
> pointer. It implicitly
> (lldb) fr v
> (lldb) po offset
> error: :3:1: error: use of unresolved identifier 'offset'
> offset
> ^~
> (lldb) fr v offset
> error: no variable named 'offset' found in this frame
> (lldb) s
> Process 13833 stopped
> * thread #1: tid = 0x3a6ffe, 0x0001000c3603 
> libswiftCore.dylib`ManagedBufferPointer.init(_uncheckedBufferClass : 
> AnyObject.Type, minimumCapacity : Int) -> ManagedBufferPointer 
> [inlined] Swift._roundUpImpl (Swift.UInt, toAlignment : Swift.Int) -> 
> Swift.UInt at Builtin.swift:58, queue = 'com.apple.main-thread', stop reason 
> = step in
> frame #0: 0x0001000c3603 
> libswiftCore.dylib`ManagedBufferPointer.init(_uncheckedBufferClass : 
> AnyObject.Type, minimumCapacity : Int) -> ManagedBufferPointer 
> [inlined] Swift._roundUpImpl (Swift.UInt, toAlignment : Swift.Int) -> 
> Swift.UInt at Builtin.swift:58 [opt]
>55   _sanityCheck(_isPowerOf2(alignment))
>56   // Note, given that offset is >= 0, and alignment > 0, we 
> don't
>57   // need to underflow check the -1, as it can never underflow.
> -> 58   let x = offset + UInt(bitPattern: alignment) &- 1
>59   // Note, as alignment is a power of 2, we'll use masking to 
> efficiently
>60   // get the aligned value
>61   return x & ~(UInt(bitPattern: alignment) &- 1)
> (lldb) fr v
> (lldb) fr v -R
> (lldb) fr v aligment
> error: no variable named 'aligment' found in this frame
> (lldb) fr v alignment
> error: no variable named 'alignment' found in this frame
> ___
> 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] Long compilation times

[Michael Gottesman via swift-users]

> On Aug 19, 2016, at 9:23 PM, Diego Sánchez via swift-users 
>  wrote:
> 
> Hi all,
> 
> We're suffering from very long Swift compilation times in our project. Each 
> file takes ~1 second to compile (-Onone), (measured with xctool -jobs 1), 
> which is hitting our development experience as we keep adding swift code 
> (~350 .swift files) :(
> 
> I've gone through all the googling already and the debug-time-function-bodies 
> thing, but I didn't find any particular function taking too long. However, I 
> did notice:
>  a) Each file takes more or less the same amount of time to compile (~1 
> second), even for very simple files.
>  b) Each "swift -frontend -c" command with the debug-time-function-bodies 
> dumps basically the same info for each file, which is around 1500 lines. Most 
> of the times are 0.0ms, and the total sum for a random choice gave me 167.3 
> ms, far away from 1 second
> 
> From a) and b) looks like the same heavy operation is being performed for 
> each file (type checking?) and that this heavy operation grows with the size 
> of the project. Would it be possible to do this upfront and not pay for it in 
> every file? Basically, if I have 3 classes in one file it will take 1 second 
> to compile them but if I do 1 file per class then it will be 3 seconds :(
> 
> I'd like some input to whether my assumption is correct and suggestions on 
> how to improve the compilation time, apart from splitting the code into 
> smaller frameworks. Can I expect improvements with Swift 3 or future 
> releases? (I tried migrating a small framework to Swift 3 and didn't see a 
> big difference)

Do you have a small example of this? Can you file a bug on bugs.swift.org 
?

Then we can look at your specific example.

> 
> Cheers,
> Diego
> 
> 
> ___
> 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] Pointer conversions between different sockaddr types

[Michael Gottesman via swift-users]

> On Aug 19, 2016, at 1:58 PM, Andrew Trick via swift-users 
>  wrote:
> 
> 
>> On Aug 18, 2016, at 12:28 AM, Quinn The Eskimo! via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> 
>> On 17 Aug 2016, at 18:55, Martin R via swift-users > > wrote:
>> 
>>> - Are both solutions correct, should one be preferred, or are both wrong?
>> 
>> Your `withMemoryRebound` solution is correct.
> 
> Absolutely, withMemoryRebound is always safe. You can use it whenever you 
> just need to reinterpret memory at a call site and know the number of values 
> stored that memory location. In this case it’s “easy" because you’re dealing 
> a single sockaddr_in.
> 
> The UnsafeRawPointer proposal is the definitive reference
> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md
>  
> 
> 
> But this migration guide is more approachable… it’s still WIP:
> https://gist.github.com/atrick/0283ae0e284610fd21ad6ed3f454a585 
> 
> 
>>> - Can the same be achieved simpler?
>> 
>> Not without introducing a layer of abstraction.
>> 
>> In my case I introduced an abstract `Address` type (basically a wrapper 
>> around `sockaddr_storage`) and then added a method to that object which 
>> calls a closure with the right parameters (actually, multiple such methods, 
>> depending on whether I’m calling something like `connect` which takes an 
>> address, or `getpeername`, which returns one).  This approach concentrates 
>> all the ugly in one place, making the rest of my BSD Sockets code much 
>> cleaner.
> 
> This is an annoying UpdatePointer migration case because it falls under the 
> category of misbehaving C APIs that we deliberately don't want to encourage 
> in Swift.
> 
> The only good answer is to provide a Swift wrapper on top of the socket API 
> as Quinn has done. It would be nice to post that code at some point so users 
> of the socket API can copy-paste into their project.

I wonder if we could provide it via an overlay or if it is a more general thing 
that could use a generic/protocol? Just a random thought.

> 
> -Andy
> ___
> 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] Building Swift 3 under ArchLinux

[Michael Gottesman via swift-users]

> On Jul 17, 2016, at 12:58 PM, Farhan Ahmed via swift-users 
>  wrote:
> 
> Thanks Kyle for the help and link to the swiftenv. I didn’t know it was 
> available, and was wondering if there was one available… saves me the trouble 
> of writing one ;)
> 
> I have all dependencies installed. The error seems to be that the 
> docs/tools/swift.1 file that is created is zero bytes, so I am thinking that 
> that file should not be zero bytes… back to figuring out why that file is 
> zero bytes.
> 
> As an aside, to me this looks like it is trying to build docs or something 
> non-essential, therefore why throw an error, and not a warning and continue 
> with the build? (this is a question for you Swift build managers! … if anyone 
> from there is reading this.) 

I can't speak to that specific issue, but if you want to turn off docs in your 
build, the cmake option you want is -DSWIFT_INCLUDE_DOCS=false.

Michael

> 
> Best,
> Farhan
> 
>> On Jul 17, 2016, at 5:14 AM, Kyle Fuller via swift-users 
>>  wrote:
>> 
>> Hi Farhan,
>> 
>> To build Swift on ArchLinux you will need to install the perl package which 
>> includes pod2man. I think the list of dependencies at 
>> https://swiftenv.fuller.li/en/latest/building-swift.html#arch-linux is 
>> correct and should contain everything you need.
>> 
>>   $ pacman -S perl libbsd icu git libedit python2 clang make ninja
>> 
>> Hope this helps,
>> 
>> Kyle
>> 
>>> Hi,
>>> 
>>> I am hoping someone would be able to help with the following problem:
>>> 
>>> I am trying to build Swift 3 under ArchLinux. I have followed the build 
>>> instructions and everything has been cloned and kick off the build by 
>>> typing: ./swift/utils/build-script -R
>>> 
>>> After a long while the build errors out at (emphasis mine):
>>> 
>>> copying static files... done
>>> copying extra files... done
>>> dumping search index in English (code: en) ... done
>>> dumping object inventory... done
>>> build succeeded.
>>> [574/574] Generating swift.1
>>> FAILED: docs/tools/swift.1 
>>> cd /home/insha/build/Ninja-ReleaseAssert/swift-linux-x86_64/docs/tools && 
>>> /usr/bin/core_perl/pod2man --section 1 --center Swift\ Documentation 
>>> --release --name swift --stderr /home/insha/swift/docs/tools/swift.pod > 
>>> /home/insha/build/Ninja-ReleaseAssert/swift-linux-x86_64/docs/tools/swift.1
>>> Can't open swift: No such file or directory at /usr/bin/core_perl/pod2man 
>>> line 70.
>>> ninja: build stopped: subcommand failed.
>>> ./swift/utils/build-script: fatal error: command terminated with a non-zero 
>>> exit status 1, aborting
>>> 
>>> So what am I doing wrong? What can I do to either fix this issue or skip it 
>>> if it is not essential (i.e. docs, etc.)? Any help and pointers would be 
>>> greatly appreciated.
>>> 
>>> Best,
>>> Farhan
>>> 
>> 
>> ___
>> 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] problems with simple binary-trees program

[Michael Gottesman via swift-users]

> On Dec 23, 2015, at 11:32 AM, Pascal Urban  wrote:
> 
>> 
>> On 22.12.2015, at 21:40, Michael Gottesman > > wrote:
>> 
>> 
>>> On Dec 22, 2015, at 2:31 PM, Pascal Urban via swift-users 
>>> mailto:swift-users@swift.org>> wrote:
>>> 
 
 On 20.12.2015, at 19:54, Maurus Kühne via swift-users 
 mailto:swift-users@swift.org>> wrote:
 
>>> …
 I was able to speed up David’s solution by almost 50% by changing the 
 method checkTree from this:
 
 func checkTree(t: Array, _ i: Int) -> Int
 
 to this:
 
 func checkTree(inout t: Array, _ i: Int) -> Int
 
 It completes in about ~10s instead of ~20s on my 2.66GHz i5 iMac for n=20. 
 This also works together with Pascal’s libdispatch solution. In this case 
 it completes in ~5s.
 Here is the modified version: 
 https://gist.github.com/mauruskuehne/633789417c2357a6bb93 
 
 
 Could somebody explain to me why this is the case? I know what the inout 
 keyword does, but I don’t understand why it makes the code faster in this 
 case?
 
 Maurus
 
 ___
 swift-users mailing list
 swift-users@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-users 
 
>>> 
>>> 
>>> Like Janosch said: ARC overhead
>>> 
>>> So here is whats happening:
>>> A function reference parameter gets retained before calling the function 
>>> and then released within the called function (generally), so the function 
>>> is taking ownership of the parameter. [1]
>>> If a parameter is marked with the inout keyword the function does not take 
>>> ownership of the reference parameter, so no retains and releases. [2]
>>> 
>>> Given how often checkTree is called the retains and releases of the array 
>>> get quiet expensive.
>>> You can see this quiet nicely while profiling these functions in 
>>> Instruments using the time profiler.
>>> 
>>> I think normally this shouldn't be a problem, but because of the recursion 
>>> the compiler is not able to optimize the retain and release calls.
>> 
>> This is not true. We can hit this case. It requires further work in the ARC 
>> optimizer. We some time ago actually did have the functionality to hit this 
>> case, but I had to disable it b/c of some correctness issues.
>> 
>> File a bug with this test case and assign to me.
> 
> Nice. I figured that this would be optimized in the future.
> Filed as SR-356 with a simplified test case.
> 

Thanks!

Michael

>> Michael
>> 
>>> 
>>> Another solution could be some kind of wrapper struct/class which has the 
>>> array as a property and checkTree as a method.
>>> This way checkTree would only access the property and additional 
>>> retains/releases would not be necessary.
>>> 
>>> [1] 
>>> https://github.com/apple/swift/blob/master/docs/SIL.rst#reference-counts 
>>> 
>>> [2] https://github.com/apple/swift/blob/master/docs/SIL.rst#inout-arguments 
>>> 
>>> 
>>> 
 On 20.12.2015, at 17:12, Janosch Hildebrand via swift-users 
 mailto:swift-users@swift.org>> wrote:
 
 Basically just rewrite a C example in Swift; not pretty but it should also 
 perform very much like C then.
>>> 
>>> 
>>> Someone has done this and is now in second place:
>>> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=swift&id=5
>>>  
>>> 
>>> 
>>> 
>>> 
>>>  ___
>>> 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_abortRetainUnowned when capturing @objc class as unowned

[Michael Gottesman via swift-users]

> On Dec 23, 2015, at 6:31 AM, Tadeas Kriz via swift-users 
>  wrote:
> 
> Hey,
> 
> I am experiencing this strange crashing when capturing an instance of a @objc 
> class (written in swift, but annotated with @objc and subclass of NSObject). 
> It happens when the closure is being assigned and not when called, so the 
> problem is not that the captured value would get deallocated and then the 
> closure called. It happens randomly, sometimes it crashes sooner, sometimes 
> later. I was experiencing this bug in earlier versions of Swift (I think it 
> was Swift 1.2), but now I'm using 2.1 and getting this crash too.
> 
> It works well when I change `[unowned x]` to `[weak x]` and then access it by 
> force unwrapping `x!.doSomething()` which leads me to believe it is a bug in 
> Swift, rather than in my code. However before opening a ticket at 
> bugs.swift.org , I wanted to get more eyes on this to 
> make sure I'm not missing anything.

Do you have a small test case? Can you file a bug?

Michael

> 
> It was also mentioned here:
> http://www.codeproject.com/Articles/791304/Resolving-strong-references-between-Swift-and-Obje
>  
> 
> here:
> https://www.reddit.com/r/swift/comments/3vhwmj/unowned_bug_in_closure_causes_attempted_to_retain/
>  
> 
> and here:
> https://forums.developer.apple.com/thread/9873 
> 
>  ___
> 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] scientific library for swift?

[Michael Gottesman via swift-users]

Have you tried using a module map with the many c libraries available?

+Steve in case he has any thoughts here.

Michael

> On Dec 22, 2015, at 4:13 PM, Jonas Fredriksson via swift-users 
>  wrote:
> 
> hi
> 
> is there any scientific library available to swift under ubuntu? like gsl for 
> C. I am especially looking for matrix manipulation and fourier functions. 
>  ___
> 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] problems with simple binary-trees program

[Michael Gottesman via swift-users]

> On Dec 22, 2015, at 2:31 PM, Pascal Urban via swift-users 
>  wrote:
> 
>> 
>> On 20.12.2015, at 19:54, Maurus Kühne via swift-users > > wrote:
>> 
> …
>> I was able to speed up David’s solution by almost 50% by changing the method 
>> checkTree from this:
>> 
>> func checkTree(t: Array, _ i: Int) -> Int
>> 
>> to this:
>> 
>> func checkTree(inout t: Array, _ i: Int) -> Int
>> 
>> It completes in about ~10s instead of ~20s on my 2.66GHz i5 iMac for n=20. 
>> This also works together with Pascal’s libdispatch solution. In this case it 
>> completes in ~5s.
>> Here is the modified version: 
>> https://gist.github.com/mauruskuehne/633789417c2357a6bb93 
>> 
>> 
>> Could somebody explain to me why this is the case? I know what the inout 
>> keyword does, but I don’t understand why it makes the code faster in this 
>> case?
>> 
>> Maurus
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> 
> 
> 
> Like Janosch said: ARC overhead
> 
> So here is whats happening:
> A function reference parameter gets retained before calling the function and 
> then released within the called function (generally), so the function is 
> taking ownership of the parameter. [1]
> If a parameter is marked with the inout keyword the function does not take 
> ownership of the reference parameter, so no retains and releases. [2]
> 
> Given how often checkTree is called the retains and releases of the array get 
> quiet expensive.
> You can see this quiet nicely while profiling these functions in Instruments 
> using the time profiler.
> 
> I think normally this shouldn't be a problem, but because of the recursion 
> the compiler is not able to optimize the retain and release calls.

This is not true. We can hit this case. It requires further work in the ARC 
optimizer. We some time ago actually did have the functionality to hit this 
case, but I had to disable it b/c of some correctness issues.

File a bug with this test case and assign to me.

Michael

> 
> Another solution could be some kind of wrapper struct/class which has the 
> array as a property and checkTree as a method.
> This way checkTree would only access the property and additional 
> retains/releases would not be necessary.
> 
> [1] https://github.com/apple/swift/blob/master/docs/SIL.rst#reference-counts 
> 
> [2] https://github.com/apple/swift/blob/master/docs/SIL.rst#inout-arguments 
> 
> 
> 
>> On 20.12.2015, at 17:12, Janosch Hildebrand via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> Basically just rewrite a C example in Swift; not pretty but it should also 
>> perform very much like C then.
> 
> 
> Someone has done this and is now in second place:
> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=swift&id=5
>  
> 
> 
> 
> 
>  ___
> 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] Design and performance of Vector2/3/4 and Matrix

[Michael Gottesman via swift-users]

> On Dec 18, 2015, at 5:13 PM, David Turnbull via swift-users 
>  wrote:
> 
> On Fri, Dec 18, 2015 at 2:31 PM, Janosch Hildebrand via swift-users 
> mailto:swift-users@swift.org>> wrote:
> You will also want to have this code in the same module that is using this 
> type.
> If you're using these types from another module you're limited to 
> unspecialized generics which are (unsurprisingly) very slow.
> 
> This is becoming clear. Hopefully these patterns can be optimized across 
> modules eventually. It's easy enough to write a pre-processor that expands 
> the generics into four specializations. But it doesn't solve everything so 
> not a priority.

We do want to be able to perform these sorts of optimizations (among others) 
across module boundaries. The reason that it has not been implemented yet is 
that the model for when/how one could (for instance) inline across module 
boundaries is not finalized. This will be possible once the resilience feature 
is complete.

>  
> And since you probably need to drop generics anyway it might make sense to 
> simply wrap the respective GLKit types on OS X and iOS for the GLFloat 
> variants as they are already highly optimized. I have some wrappers for the 
> GLKMatrix and GLKVector types lying around in my own OpenGL wrapper 
> (incidentally also named SwiftGL ;-)) which might save you some typing if 
> you're interested...
> 
> I'm trailblazing cross-platform OpenGL in Swift. Given there's only one other 
> platform, the key question is, "Does it work on Linux?"
> 
> Is your SwiftGL online somewhere? A cursory search didn't yield anything. 
> 
> -david (https://github.com/AE9RB/SwiftGL )
> 
> 
>  ___
> 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