Re: [swift-users] Importing C system libraries

I feel your pain ;-) Just embrace the dark side, it takes a little time to get used to, but chances are you won’t regret it. Btw: I still do my development in Xcode, its just that using the SPM (Swift Package Manager) and git from the command line gives a whole extra dimension to my productivi

Re: [swift-users] Why does this leak?

> On 28 Mar 2017, at 05:41, Rick Aurbach wrote: > > That wouldn’t work directly. The “leak” occurs when processing a segue called > in response to a user button push. (I suppose I could attempt to wire up a UI > Test, but would rather not go down that route.) > > What I can try is to see if I

Re: [swift-users] Importing C system libraries

CLI’s are nothing to be afraid of :) tbh I find XCode much more difficult to work with than files and command line invocations. On Mon, Mar 27, 2017 at 4:16 PM, Michael Ilseman wrote: > I don’t know what you’re referring to, but my solution also works for > pre-open-source versions of Swift. > >

Re: [swift-users] Importing C system libraries

Can you give an example? On Mon, Mar 27, 2017 at 3:59 PM, Michael Ilseman wrote: > Sure. At a low level, you can create a module.map file and use -L/-l flags > in your invocation of Swift. If you want to do so at a higher level, then > perhaps SwiftPM can. CCing swift-build-dev for the SwiftPM p

Re: [swift-users] Asynchronous error recovering with RecoverableError

Hi Dennis, Thanks for your answer. I can see that my message needs some more context: RecoverableError is a protocol in the standard library that can be implemented to opt in to the error recovery mechanism available on macOS. attemptRecovery(optionIndex, resultHandler:) is one of the methods t

Re: [swift-users] Importing C system libraries

Sure! In this example, I have built libgit2. I have a directory called Git, and inside that I have the following module map: module Git [system] { header "/libgit2/include/git2.h" export * } When I run, I use: swift -I -L -lgit2 foo.swift inside foo.swift I can: import Git //

Re: [swift-users] Asynchronous error recovering with RecoverableError

CC Doug Gregor, who git blame tells me wrote this part. Doug, this slightly predates noescape-by-default. Is this a bug or as intended? > On Mar 28, 2017, at 8:49 AM, Elia Cereda via swift-users > wrote: > > Hi Dennis, > > Thanks for your answer. I can see that my message needs some more con

Re: [swift-users] Improving compilation times?

I’ve had the same issue and adding a user-defined setting `SWIFT_WHOLE_MODULE_OPTIMIZATION = YES` seemed to fix this. Down from 12 minutes to 2.5 after clean -> build. The question is why do we have to set such flags in Xcode ourselves, when it most probably should be the default setting? > W

Re: [swift-users] Improving compilation times?

That setting breaks incremental compilation, so you're getting clean build speed at the expense of incremental builds. Jon > On Mar 28, 2017, at 7:35 AM, Bartłomiej Nowak via swift-users > wrote: > > I’ve had the same issue and adding a user-defined setting > `SWIFT_WHOLE_MODULE_OPTIMIZAT

Re: [swift-users] Why does this leak?

This is getting interesting. I added your suggested test code (set to execute once): class FontSelectorDialog : UITableViewController { static let chooser : ColorChooser = ColorChooser() override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(a

[swift-users] Foundation: build.ninja No such file or directory

I am trying to build Foundation and is anybody else getting build.ninja: No such file or directory error? I just cloned everything from github. This did not happen with me when I worked on my previous pull request. Cheers! -- Mohit Athwani http://about.me/mohitathwani__

Re: [swift-users] Improving compilation times?

Jon, I enabled this setting in a Swift 3.1 project in Xcode 8.3 and incremental builds work as usual. The project does not recompile when making small changes. But I did notice a great decrease in build time for my project. Maybe the recompiles only happen on big changes? Because when I change on

Re: [swift-users] Foundation: build.ninja No such file or directory

What host os are you attempting to build on? For linux you need to have a configured Foundation initially to run ninja. This means that you need to build swift with the build-script including --foundation and --libdispatch and --xctest After one successful build you can run ninja in the Foundat

[swift-users] Foundation: build.ninja No such file or directory

Hey guys, I am trying to build Foundation and is anybody else getting build.ninja: No such file or directory error? I just cloned everything from github. This did not happen with me when I worked on my previous pull request. Cheers! Mohit ___ swift-us

Re: [swift-users] Foundation: build.ninja No such file or directory

Hi Phillipe, I'm doing this on Ubuntu 16.04 LTS and I first ran: swift/utils/build-script --xctest --foundation -t and then cd swift-corelibs-foundation ninja I wonder why this is happening! Thanks for your help! Mohit On Tue, Mar 28, 2017 at 12:31 PM, Philippe Hausler wrote: > What host

[swift-users] Set with element of NSObject subclasses didn't work as expected

Please see the code first. import Foundation class Foo:Hashable { let value:Int public var hashValue: Int { return value } public static func ==(lhs: Foo, rhs: Foo) -> Bool { return lhs.value == rhs.value } init(_ value:Int) { self.value = value

Re: [swift-users] [swift-build-dev] Importing C system libraries

> On Mar 28, 2017, at 1:58 AM, Rien via swift-build-dev > wrote: > > I feel your pain ;-) > > Just embrace the dark side, it takes a little time to get used to, but > chances are you won’t regret it. > > Btw: I still do my development in Xcode, its just that using the SPM (Swift > Package M

Re: [swift-users] Asynchronous error recovering with RecoverableError

> On Mar 28, 2017, at 11:21 AM, Michael Ilseman wrote: > > CC Doug Gregor, who git blame tells me wrote this part. > > Doug, this slightly predates noescape-by-default. Is this a bug or as > intended? It’s a bug; the point here is that we can do recovery asynchronously, so it should be @esca

Re: [swift-users] Asynchronous error recovering with RecoverableError

New start task: https://bugs.swift.org/browse/SR-4405 Add @escaping to RecoverableError.attemptRecovery > On Mar 28, 2017, at 3:31 PM, Douglas Gregor wrote: > > >> On Mar 28, 2017, at 11:21 AM, Michael Ilseman > > wrote: >>

Re: [swift-users] [swift-build-dev] Importing C system libraries

I can only fit one monitor in my dorm and it’s honestly tragic… On Tue, Mar 28, 2017 at 2:58 PM, David Sweeris wrote: > > On Mar 28, 2017, at 1:58 AM, Rien via swift-build-dev < > swift-build-...@swift.org> wrote: > > I feel your pain ;-) > > Just embrace the dark side, it takes a little time to

Re: [swift-users] Importing C system libraries

How do I compile a project with many modules? My tree looks like this: ​ On Tue, Mar 28, 2017 at 12:47 PM, Michael Ilseman wrote: > Sure! In this example, I have built libgit2. I have a directory called > Git, and inside that I have the following module map: > > module Git [system] { >

Re: [swift-users] Importing C system libraries

This is into uncharted territory for me, but it seems you’re building with SwiftPM. You’ll probably want to configure extra compiler flags if that’s possible. You could also bite the bullet and build your C libraries with SwiftPM as well. Hopefully someone on swift-build-dev can help you out. C

Re: [swift-users] Set with element of NSObject subclasses didn't work as expected

Turns out that for `NSObject`, protocol `Equatable` wasn't used. Instead, it used `NSObjectProtocol.isEqual(_ object: Any?)`. Also, override `func isEqual(_ object: Any?) -> Bool` requires to override `var hash: Int { get }` as well. I think this behavior should be mentioned in Swift docs or manua

Re: [swift-users] Set with element of NSObject subclasses didn't work as expected

NSObject’s hash (which Set uses) is done via ObjectIdentifier, which IIRC uses something along the lines of the object's address. That’s why you’re getting the behavior you’re seeing. Saagar Jha > On Mar 28, 2017, at 20:20, Zhao Xin via swift-users > wrote: > > Turns out that for `NSObject`,

Re: [swift-users] Importing C system libraries

see idk how to include the libraries and still make them Importable. And dumping the library sources into the project dir would kind of hamper source distribution… > On Mar 28, 2017, at 7:36 PM, Michael Ilseman wrote: > > This is into uncharted territory for me, but it seems you’re building wi

Re: [swift-users] [swift-build-dev] Importing C system libraries

Hi, Apologies for not replying to this earlier. You can have multiple targets in a single package. Each target can either be Swift or C-family. The type of target is determined by the sources contained in it (*.c/*.cpp etc means C target, *.swift means Swift target). So if you want to create mult

Re: [swift-users] Importing C system libraries

After a lot of wasted effort I’ve found that for some reason only the SPM is capable of linking Swift code with Linux’s system libraries which are all compiled with gcc, which apparently doesn’t get along too well with clang. All I want is to be able to import a system library without making an em

Re: [swift-users] [swift-build-dev] Importing C system libraries

I will try this, but why are the header files inside the Sources directory? System headers should live in /usr/include… On Tue, Mar 28, 2017 at 11:48 PM, Ankit Aggarwal wrote: > Hi, > > Apologies for not replying to this earlier. > > You can have multiple targets in a single package. Each target

Re: [swift-users] [swift-build-dev] Importing C system libraries

In this case, these are just umbrella headers. If your modulemap contains absolute path to the header, then you don't need the header files, but SwiftPM will probably warn about this. Note that this is a "hack" to have system packages inside a single repository. The correct way is to have system

Re: [swift-users] [swift-build-dev] Importing C system libraries

This worked! Thanks! But why is having empty git repositories strewn about the “correct” way? System libraries should be imported from within the project, as they are in C. You have to admit it’s getting quite silly that Swift devs keep repositories like these

Re: [swift-users] [swift-build-dev] Importing C system libraries

I think the idea was that there will be one such repository which other packages can use, that too only until the system libraries start shipping their standard modulemap. I thought we had this written down in our documentation somewhere but couldn't find it. Maybe Daniel can expand on this. On W

Re: [swift-users] [swift-build-dev] Importing C system libraries

I figured that was the intention, but we can’t be too surprised that everyone is maintaining personal modulemap repositories (and polluting search results — just try googling for a Swift PNG library!), especially when this central repo still doesn’t exist yet. If Swift ever comes on par with C

Re: [swift-users] [swift-build-dev] Importing C system libraries

> On 29-Mar-2017, at 11:22 AM, kelvinsthirt...@gmail.com wrote: > > I figured that was the intention, but we can’t be too surprised that everyone > is maintaining personal modulemap repositories (and polluting search results > — just try googling for a Swift PNG library!), especially when this