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]

nd LLDB
>>>> 
>>>> Swift doesn’t seem to be reporting whatever the error is, I just see:
>>>> 
>>>> ((SwiftASTContext*)0x7f8c555c84a0)->GetModule('PerfectTemplate') -- failed 
>>>> with no error
>>>> 
>>>> That’s not very helpful.  Again, I’ll probably need to make this happen 
>>>> locally to see what went wrong.  If you have a project that shows the 
>>>> issue which you can make available, please file a bug with a description 
>>>> of how you build and debug this app, I’ll take a look.
>>>> 
>>>> Jim
>>>> 
>>>> 
>>>>> On Nov 6, 2017, at 12:56 PM, ⁨‫Fadi Botros‬ ‫⁩ <⁨botros_f...@yahoo.com 
>>>>> <mailto:botros_f...@yahoo.com>⁩> wrote:
>>>>> 
>>>>> OK
>>>>> Here is when captured "print self" log from the beginning
>>>>> 
>>>>> Attached here is the full log file
>>>>> See the attachments
>>>>> من: Jim Ingham <jing...@apple.com <mailto:jing...@apple.com>>
>>>>> إلى: ‫Fadi Botros‬ ‫ <botros_f...@yahoo.com 
>>>>> <mailto:botros_f...@yahoo.com>> 
>>>>> نسخة كربونية: Michael Gottesman <mgottes...@apple.com 
>>>>> <mailto:mgottes...@apple.com>>; "swift-users@swift.org 
>>>>> <mailto:swift-users@swift.org>" <swift-users@swift.org 
>>>>> <mailto:swift-users@swift.org>>
>>>>> تاريخ الإرسال: الإثنين 6 نوفمبر، 2017‏ 10:15 م
>>>>> الموضوع: Re: [swift-users] About Swift Package Manager and LLDB
>>>>> 
>>>>> The log for “print self” was unfortunately captured too late.  Reading in 
>>>>> the PerfectTemplate module had already failed, and so any subsequent 
>>>>> attempt will just report 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 <mgottes...@apple.com 
>>>>>> <mailto:mgottes...@apple.com>>
>>>>>> إلى: Michae

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 <mgottes...@apple.com>
> إلى: Michael Gottesman <mgottes...@apple.com> 
> نسخة كربونية: "swift-users@swift.org" <swift-users@swift.org>; ‫Fadi Botros‬ 
> ‫ <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 
>> <swift-users@swift.org <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]

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 
>> > 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] 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 
> > 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 <mohit.athw...@gmail.com> 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 <mgottes...@apple.com 
> <mailto:mgottes...@apple.com>> wrote:
> No worries. Just trying to be helpful = ).
> 
> Michael
> 
>> On Apr 2, 2017, at 12:27 PM, Mohit Athwani <mohit.athw...@gmail.com 
>> <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 <mgottes...@apple.com 
>> <mailto:mgottes...@apple.com>>, wrote:
>>> Hey Mohit!
>>> 
>>> Were you able to build successfully?
>>> 
>>> Michael
>>> 
>>>> On Mar 30, 2017, at 4:29 PM, Michael Gottesman <mgottes...@apple.com 
>>>> <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 <mgottes...@apple.com 
>>>>> <mailto:mgottes...@apple.com>> wrote:
>>>>> 
>>>>>> 
>>>>>> On Mar 30, 2017, at 4:22 PM, Michael Gottesman via swift-users 
>>>>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> On Mar 30, 2017, at 12:31 PM, Mohit Athwani via swift-users 
>>>>>>> <swift-users@swift.org <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 
>

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 <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 <mgottes...@apple.com 
>> <mailto:mgottes...@apple.com>> wrote:
>> 
>>> 
>>> On Mar 30, 2017, at 4:22 PM, Michael Gottesman via swift-users 
>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>> 
>>>> 
>>>> On Mar 30, 2017, at 12:31 PM, Mohit Athwani via swift-users 
>>>> <swift-users@swift.org <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>
>>> 
>>

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 <mgottes...@apple.com> wrote:
> 
>> 
>> On Mar 30, 2017, at 4:22 PM, Michael Gottesman via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> 
>>> 
>>> On Mar 30, 2017, at 12:31 PM, Mohit Athwani via swift-users 
>>> <swift-users@swift.org <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 
> <swift-users@swift.org> wrote:
> 
>> 
>> On Mar 30, 2017, at 12:31 PM, Mohit Athwani via swift-users 
>> <swift-users@swift.org <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 
>> > 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 
> <swift-users@swift.org> 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 <mgottes...@apple.com 
>> <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 
>>> <swift-users@swift.org <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 
> > 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 
> > 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] 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 
>> > 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] 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 
>>> > 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.
> 
> 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 
 > 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=swift=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 
> > 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