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

[taylor swift via swift-users]

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 in terms of being usage and the lingua franca 
of the FOSS world, I can see linux distributions shipping standard modulemaps 
the same way they ship C headers, but you have to admit this is years 
(decades?) away at best.

On the flip side of it, it does wonders in terms of motivating people (me at 
least) to start writing pure Swift replacements for some of these C libraries 
(like libpng)…

> On Mar 29, 2017, at 12:42 AM, Ankit Aggarwal  wrote:
> 
> 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 Wed, Mar 29, 2017 at 10:48 AM, Kelvin Ma via swift-build-dev 
>>  wrote:
>> 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 on our github accounts. That zlib 
>> repository contains exactly ten lines of code. I used to have 6 or 7 repos 
>> like that one up there before I got rid of them and switched to local repos. 
>> 
>>> On Wed, Mar 29, 2017 at 12:03 AM, Ankit Aggarwal  
>>> wrote:
>>> 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 package as a separate published package which you only need to do 
>>> once.
>>> 
 On 29-Mar-2017, at 10:26 AM, Kelvin Ma  wrote:
 
 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 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 multiple C targets, this layout should 
> work:
> 
> Package.swift
> Sources/
> Bitmap
> Cubify
> Cairo/anchor.c < This is just an empty file to tell SwiftPM that 
> this is a C target.
> Cairo/include/Cairo.h
> Cairo/include/module.modulemap
> GLFW/anchor.c
> GLFW/include/GLFW.h
> GLFW/include/module.modulemap
> 
> The modulemap is automatically generated, if not provided. This is a 
> package which contains two targets (one C and one Swift): 
> https://github.com/jpsim/Yams
> 
> If you need to pass a bunch of compiler flags, you can use SwiftPM's 
> pkgConfig feature but that will require you to have a separate repository 
> for Cario and GLFW. You can experiment without creating tags using the 
> edit feature.
> 
> PS: You can join SwiftPM slack channel for quicker turn around time: 
> https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160530/000497.html
> 
> Thanks,
> Ankit
> 
> 
>> On Wed, Mar 29, 2017 at 6:06 AM, Michael Ilseman via swift-build-dev 
>>  wrote:
>> 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.
>> 
>> CC-ing Ankit
>> 
>> 
>>> On Mar 28, 2017, at 5:09 PM, Kelvin Ma  
>>> wrote:
>>> 
>>> 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] {
header "/libgit2/include/git2.h"
export *
 }
 
 

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

[Ankit Aggarwal via swift-users]

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 Wed, Mar 29, 2017 at 10:48 AM, Kelvin Ma via swift-build-dev <
swift-build-...@swift.org> wrote:

> 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
>  on our github accounts. That
> zlib repository contains exactly ten lines of code. I used to have 6 or 7
> repos like that one up there before I got rid of them and switched to local
> repos.
>
> On Wed, Mar 29, 2017 at 12:03 AM, Ankit Aggarwal  > wrote:
>
>> 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 package as a separate published package which you only need to do
>> once.
>>
>> On 29-Mar-2017, at 10:26 AM, Kelvin Ma  wrote:
>>
>> 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 <
>> ankit_aggar...@apple.com> wrote:
>>
>>> 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 multiple C targets, this layout should
>>> work:
>>>
>>> Package.swift
>>> Sources/
>>> Bitmap
>>> Cubify
>>> Cairo/anchor.c < This is just an empty file to tell SwiftPM that
>>> this is a C target.
>>> Cairo/include/Cairo.h
>>> Cairo/include/module.modulemap
>>> GLFW/anchor.c
>>> GLFW/include/GLFW.h
>>> GLFW/include/module.modulemap
>>>
>>> The modulemap is automatically generated, if not provided. This is a
>>> package which contains two targets (one C and one Swift):
>>> https://github.com/jpsim/Yams
>>>
>>> If you need to pass a bunch of compiler flags, you can use SwiftPM's
>>> pkgConfig feature but that will require you to have a separate repository
>>> for Cario and GLFW. You can experiment without creating tags using the edit
>>> feature
>>> 
>>> .
>>>
>>> PS: You can join SwiftPM slack channel for quicker turn around time:
>>> https://lists.swift.org/pipermail/swift-build-dev/Week
>>> -of-Mon-20160530/000497.html
>>>
>>> Thanks,
>>> Ankit
>>>
>>>
>>> On Wed, Mar 29, 2017 at 6:06 AM, Michael Ilseman via swift-build-dev <
>>> swift-build-...@swift.org> wrote:
>>>
 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.

 CC-ing Ankit


 On Mar 28, 2017, at 5:09 PM, Kelvin Ma 
 wrote:

 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] {
>header "/libgit2/include/git2.h"
>export *
> }
>
> When I run, I use:
>
> swift -I  -L  -lgit2
> foo.swift
>
> inside foo.swift I can:
>
> import Git
> // … use libGit2
>
>
> Read more about how to write a more appropriate module.map file for
> your purposes at https://clang.llvm.org/docs/Modules.html. For
> example, you might be able to define link flags inside the module.map, use
> umbrella directories, submodules, etc.
>
>
>
> On Mar 28, 2017, at 6:27 AM, Kelvin Ma 
> wrote:
>
> 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,
>> 

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

[Kelvin Ma via swift-users]

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
 on our github accounts. That zlib
repository contains exactly ten lines of code. I used to have 6 or 7 repos
like that one up there before I got rid of them and switched to local
repos.

On Wed, Mar 29, 2017 at 12:03 AM, Ankit Aggarwal 
wrote:

> 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 package as a separate published package which you only need to do
> once.
>
> On 29-Mar-2017, at 10:26 AM, Kelvin Ma  wrote:
>
> 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 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 multiple C targets, this layout should work:
>>
>> Package.swift
>> Sources/
>> Bitmap
>> Cubify
>> Cairo/anchor.c < This is just an empty file to tell SwiftPM that
>> this is a C target.
>> Cairo/include/Cairo.h
>> Cairo/include/module.modulemap
>> GLFW/anchor.c
>> GLFW/include/GLFW.h
>> GLFW/include/module.modulemap
>>
>> The modulemap is automatically generated, if not provided. This is a
>> package which contains two targets (one C and one Swift):
>> https://github.com/jpsim/Yams
>>
>> If you need to pass a bunch of compiler flags, you can use SwiftPM's
>> pkgConfig feature but that will require you to have a separate repository
>> for Cario and GLFW. You can experiment without creating tags using the edit
>> feature
>> 
>> .
>>
>> PS: You can join SwiftPM slack channel for quicker turn around time:
>> https://lists.swift.org/pipermail/swift-build-dev/Week
>> -of-Mon-20160530/000497.html
>>
>> Thanks,
>> Ankit
>>
>>
>> On Wed, Mar 29, 2017 at 6:06 AM, Michael Ilseman via swift-build-dev <
>> swift-build-...@swift.org> wrote:
>>
>>> 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.
>>>
>>> CC-ing Ankit
>>>
>>>
>>> On Mar 28, 2017, at 5:09 PM, Kelvin Ma 
>>> wrote:
>>>
>>> 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] {
header "/libgit2/include/git2.h"
export *
 }

 When I run, I use:

 swift -I  -L  -lgit2
 foo.swift

 inside foo.swift I can:

 import Git
 // … use libGit2


 Read more about how to write a more appropriate module.map file for
 your purposes at https://clang.llvm.org/docs/Modules.html. For
 example, you might be able to define link flags inside the module.map, use
 umbrella directories, submodules, etc.



 On Mar 28, 2017, at 6:27 AM, Kelvin Ma 
 wrote:

 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 part.
>
>
> > On Mar 26, 2017, at 3:20 PM, Kelvin Ma via swift-users <
> swift-users@swift.org> wrote:
> >
> > Idk if this has been asked before, but is there a way to import C
> libraries into a Swift project without creating a local git repo?
> Preferably something similar to C where you can just `#include` headers 
> and
> then specify the link flags (in Package.swift?)
> >
> > It’s getting very cumbersome to make a bunch of empty 

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

[Ankit Aggarwal via swift-users]

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 package 
as a separate published package which you only need to do once.

> On 29-Mar-2017, at 10:26 AM, Kelvin Ma  wrote:
> 
> 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 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 multiple C targets, this layout should work:
> 
> Package.swift
> Sources/
> Bitmap
> Cubify
> Cairo/anchor.c < This is just an empty file to tell SwiftPM that this 
> is a C target.
> Cairo/include/Cairo.h
> Cairo/include/module.modulemap
> GLFW/anchor.c
> GLFW/include/GLFW.h
> GLFW/include/module.modulemap
> 
> The modulemap is automatically generated, if not provided. This is a package 
> which contains two targets (one C and one Swift): 
> https://github.com/jpsim/Yams 
> 
> If you need to pass a bunch of compiler flags, you can use SwiftPM's 
> pkgConfig feature but that will require you to have a separate repository for 
> Cario and GLFW. You can experiment without creating tags using the edit 
> feature 
> .
> 
> PS: You can join SwiftPM slack channel for quicker turn around time: 
> https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160530/000497.html
>  
> 
> 
> Thanks,
> Ankit
> 
> 
> On Wed, Mar 29, 2017 at 6:06 AM, Michael Ilseman via swift-build-dev 
> > wrote:
> 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.
> 
> CC-ing Ankit
> 
> 
>> On Mar 28, 2017, at 5:09 PM, Kelvin Ma > > wrote:
>> 
>> 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] {
>>header "/libgit2/include/git2.h"
>>export *
>> }
>> 
>> When I run, I use:
>> 
>> swift -I  -L  -lgit2 
>> foo.swift
>> 
>> inside foo.swift I can:
>> 
>> import Git
>> // … use libGit2
>> 
>> 
>> Read more about how to write a more appropriate module.map file for your 
>> purposes at https://clang.llvm.org/docs/Modules.html 
>> . For example, you might be able 
>> to define link flags inside the module.map, use umbrella directories, 
>> submodules, etc.
>> 
>> 
>> 
>>> On Mar 28, 2017, at 6:27 AM, Kelvin Ma >> > wrote:
>>> 
>>> 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 part.
>>> 
>>> 
>>> > On Mar 26, 2017, at 3:20 PM, Kelvin Ma via swift-users 
>>> > > wrote:
>>> >
>>> > Idk if this has been asked before, but is there a way to import C 
>>> > libraries into a Swift project without creating a local git repo? 
>>> > Preferably something similar to C where you can just `#include` headers 
>>> > and then specify the link flags (in Package.swift?)
>>> >
>>> > It’s getting very cumbersome to make a bunch of empty git repos just to 
>>> > use libglfw or libcairo.
>>> > ___
>>> > swift-users mailing list
>>> > swift-users@swift.org 
>>> > https://lists.swift.org/mailman/listinfo/swift-users 
>>> > 

Re: [swift-users] Importing C system libraries

[Michael Ilseman via swift-users]

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.

CC-ing Ankit


> On Mar 28, 2017, at 5:09 PM, Kelvin Ma  wrote:
> 
> 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] {
>header "/libgit2/include/git2.h"
>export *
> }
> 
> When I run, I use:
> 
> swift -I  -L  -lgit2 foo.swift
> 
> inside foo.swift I can:
> 
> import Git
> // … use libGit2
> 
> 
> Read more about how to write a more appropriate module.map file for your 
> purposes at https://clang.llvm.org/docs/Modules.html 
> . For example, you might be able to 
> define link flags inside the module.map, use umbrella directories, 
> submodules, etc.
> 
> 
> 
>> On Mar 28, 2017, at 6:27 AM, Kelvin Ma > > wrote:
>> 
>> 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 part.
>> 
>> 
>> > On Mar 26, 2017, at 3:20 PM, Kelvin Ma via swift-users 
>> > > wrote:
>> >
>> > Idk if this has been asked before, but is there a way to import C 
>> > libraries into a Swift project without creating a local git repo? 
>> > Preferably something similar to C where you can just `#include` headers 
>> > and then specify the link flags (in Package.swift?)
>> >
>> > It’s getting very cumbersome to make a bunch of empty git repos just to 
>> > use libglfw or libcairo.
>> > ___
>> > 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 C system libraries

[Kelvin Ma via swift-users]

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] {
>header "/libgit2/include/git2.h"
>export *
> }
>
> When I run, I use:
>
> swift -I  -L  -lgit2
> foo.swift
>
> inside foo.swift I can:
>
> import Git
> // … use libGit2
>
>
> Read more about how to write a more appropriate module.map file for your
> purposes at https://clang.llvm.org/docs/Modules.html. For example, you
> might be able to define link flags inside the module.map, use umbrella
> directories, submodules, etc.
>
>
>
> On Mar 28, 2017, at 6:27 AM, Kelvin Ma  wrote:
>
> 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 part.
>>
>>
>> > On Mar 26, 2017, at 3:20 PM, Kelvin Ma via swift-users <
>> swift-users@swift.org> wrote:
>> >
>> > Idk if this has been asked before, but is there a way to import C
>> libraries into a Swift project without creating a local git repo?
>> Preferably something similar to C where you can just `#include` headers and
>> then specify the link flags (in Package.swift?)
>> >
>> > It’s getting very cumbersome to make a bunch of empty git repos just to
>> use libglfw or libcairo.
>> > ___
>> > 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-build-dev] Importing C system libraries

[Kelvin Ma via swift-users]

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 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 productivity.
>
> I use a large monitor and have two terminal windows open at all times on
> the left side, and Xcode open on the right. Two monitors would be even
> better (I think).
>
>
> Since you mentioned it… :-D
>
> Using two monitors is a whole new world, and I cannot recommend it highly
> enough. Three is an improvement over two, but not by nearly the same margin
> as two is to one. Four is, well, I suppose better than leaving a monitor
> laying around and not doing anything… I've tried stretching my Xcode window
> really tall, but the bezels are too disruptive for me. I’ve heard more than
> one person claim that 1x 21:9 monitor is just as good as 2x 16:9/16:10
> monitors (maybe better, because the two “screens” don’t have to be the same
> size anymore), but I haven’t had a chance to try one out yet.
>
> Xcode is really amazing: when I regenerate the project in a terminal,
> there is no need to close and reopen xcode. Xcode will collapse the
> navigator, but otherwise it just refreshes with the new content. Its quite
> neat to work this way. The only two drawbacks that I have detected so far
> is that I need to “clean” more in Xcode, and that the old project settings
> are overwritten, thus if you do a lot of tweaking of the build settings
> this might not work out all that well.
>
>
> Yeah, if Xcode were open-source, I’d be working on SwiftPM integration.
> Hmm… Maybe SwiftPM can detect if a .xcodeproj file already exists and copy
> any custom settings from there before writing the new one? That might not
> be too hard, depending on how complicated those files are.
>
> - Dave Sweeris
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Michael Ilseman via swift-users]

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:
>> 
>> 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 @escaping. We missed the annotation when noescape-by-default landed.
> 
>   - Doug
> 
>> 
>> 
>>> 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 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 that 
>>> have to be implemented to conform to the protocol.
>>> 
>>> Here you can find the other ones:
>>> 
>>> /// Describes an error that may be recoverable by presenting several
>>> /// potential recovery options to the user.
>>> public protocol RecoverableError : Error {
>>> 
>>> /// Provides a set of possible recovery options to present to the user.
>>> public var recoveryOptions: [String] { get }
>>> 
>>> /// Attempt to recover from this error when the user selected the
>>> /// option at the given index. This routine must call handler and
>>> /// indicate whether recovery was successful (or not).
>>> ///
>>> /// This entry point is used for recovery of errors handled at a
>>> /// "document" granularity, that do not affect the entire
>>> /// application.
>>> public func attemptRecovery(optionIndex recoveryOptionIndex: Int, 
>>> resultHandler handler: (Bool) -> Swift.Void)
>>> 
>>> /// Attempt to recover from this error when the user selected the
>>> /// option at the given index. Returns true to indicate
>>> /// successful recovery, and false otherwise.
>>> ///
>>> /// This entry point is used for recovery of errors handled at
>>> /// the "application" granularity, where nothing else in the
>>> /// application can proceed until the attempted error recovery
>>> /// completes.
>>> public func attemptRecovery(optionIndex recoveryOptionIndex: Int) -> 
>>> Bool
>>> }
>>> 
>>> As you can see, there are two attemptRecovery methods. In my mind the first 
>>> one was meant to be used for asynchronous operations, where you run some 
>>> recovering code in background and then report its result back to the caller.
>>> 
>>> The problem is that the handler is not marked as @escaping and as such it 
>>> can only be used inside the body of attemptRecovery. I was wondering if 
>>> this was an oversight from the stdlib team or if this was a deliberate 
>>> design decision.
>>> 
>>> I just saw that the method is still not marked as @escaping in master 
>>> (https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/NSError.swift#L105
>>>  
>>> ),
>>>  so I’d like to know what its intended use case is, since the obvious one 
>>> (asynchronous recovery) is prevented by the missing annotation.
>>> 
>>> Thanks,
>>> Elia Cereda
>>> 
 Il giorno 28 mar 2017, alle ore 17:33, Dennis Weissmann 
 > ha scritto:
 
 Hey Elia,
 
 I'm currently on mobile and don't really know what you're talking about 
 (what is RecoverableError?) but you say it's a block, and if the closure 
 is optional, it is @escaping by default.
 
 Did you see 
 https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160905/003185.html
  
 
 
 - Dennis
 
 Sent from my iPhone
 
 On 23. Mar 2017, at 10:07 AM, Elia Cereda via swift-users 
 > wrote:
 
> I'd like to bump this issue, since it has been some time and it hasn't 
> been addressed.
> 
> Thanks,
> Elia Cereda
> 
> Il giorno 03 mar 2017, alle ore 21:33, Elia Cereda  > ha scritto:
> 
>> I’m wondering why the resultHandler block on 
>> RecoverableError.attemptRecovery(optionIndex, resultHandler:) is not 
>> marked @escaping?
>> 
>> I’m trying to invoke some recovering code that executes asynchronously, 
>> then reports if it was successful or not and I thought that this was the 
>> right strategy. As far as I can tell, without 

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

[Douglas Gregor via swift-users]

> 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 @escaping. We missed the annotation when noescape-by-default landed.

- Doug

> 
> 
>> 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 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 that have 
>> to be implemented to conform to the protocol.
>> 
>> Here you can find the other ones:
>> 
>> /// Describes an error that may be recoverable by presenting several
>> /// potential recovery options to the user.
>> public protocol RecoverableError : Error {
>> 
>> /// Provides a set of possible recovery options to present to the user.
>> public var recoveryOptions: [String] { get }
>> 
>> /// Attempt to recover from this error when the user selected the
>> /// option at the given index. This routine must call handler and
>> /// indicate whether recovery was successful (or not).
>> ///
>> /// This entry point is used for recovery of errors handled at a
>> /// "document" granularity, that do not affect the entire
>> /// application.
>> public func attemptRecovery(optionIndex recoveryOptionIndex: Int, 
>> resultHandler handler: (Bool) -> Swift.Void)
>> 
>> /// Attempt to recover from this error when the user selected the
>> /// option at the given index. Returns true to indicate
>> /// successful recovery, and false otherwise.
>> ///
>> /// This entry point is used for recovery of errors handled at
>> /// the "application" granularity, where nothing else in the
>> /// application can proceed until the attempted error recovery
>> /// completes.
>> public func attemptRecovery(optionIndex recoveryOptionIndex: Int) -> Bool
>> }
>> 
>> As you can see, there are two attemptRecovery methods. In my mind the first 
>> one was meant to be used for asynchronous operations, where you run some 
>> recovering code in background and then report its result back to the caller.
>> 
>> The problem is that the handler is not marked as @escaping and as such it 
>> can only be used inside the body of attemptRecovery. I was wondering if this 
>> was an oversight from the stdlib team or if this was a deliberate design 
>> decision.
>> 
>> I just saw that the method is still not marked as @escaping in master 
>> (https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/NSError.swift#L105
>>  
>> ),
>>  so I’d like to know what its intended use case is, since the obvious one 
>> (asynchronous recovery) is prevented by the missing annotation.
>> 
>> Thanks,
>> Elia Cereda
>> 
>>> Il giorno 28 mar 2017, alle ore 17:33, Dennis Weissmann 
>>> > ha scritto:
>>> 
>>> Hey Elia,
>>> 
>>> I'm currently on mobile and don't really know what you're talking about 
>>> (what is RecoverableError?) but you say it's a block, and if the closure is 
>>> optional, it is @escaping by default.
>>> 
>>> Did you see 
>>> https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160905/003185.html
>>>  
>>> 
>>> 
>>> - Dennis
>>> 
>>> Sent from my iPhone
>>> 
>>> On 23. Mar 2017, at 10:07 AM, Elia Cereda via swift-users 
>>> > wrote:
>>> 
 I'd like to bump this issue, since it has been some time and it hasn't 
 been addressed.
 
 Thanks,
 Elia Cereda
 
 Il giorno 03 mar 2017, alle ore 21:33, Elia Cereda > ha scritto:
 
> I’m wondering why the resultHandler block on 
> RecoverableError.attemptRecovery(optionIndex, resultHandler:) is not 
> marked @escaping?
> 
> I’m trying to invoke some recovering code that executes asynchronously, 
> then reports if it was successful or not and I thought that this was the 
> right strategy. As far as I can tell, without @escaping that method loses 
> all it’s purpose and becomes essentially equivalent to 
> attemptRecovery(optionIndex:).
> 
> So, I’d like to ask.
> 1. Is it a bug or that method is non-escaping on purpose?
> 2. If it is a bug, is there a workaround that can be applied pending a 
> fix in a future version of Swift?
> 3. If it was a deliberate 

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

[David Sweeris via swift-users]

> 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 Manager) and git from the command line gives a whole extra dimension 
> to my productivity.
> 
> I use a large monitor and have two terminal windows open at all times on the 
> left side, and Xcode open on the right. Two monitors would be even better (I 
> think).

Since you mentioned it… :-D

Using two monitors is a whole new world, and I cannot recommend it highly 
enough. Three is an improvement over two, but not by nearly the same margin as 
two is to one. Four is, well, I suppose better than leaving a monitor laying 
around and not doing anything… I've tried stretching my Xcode window really 
tall, but the bezels are too disruptive for me. I’ve heard more than one person 
claim that 1x 21:9 monitor is just as good as 2x 16:9/16:10 monitors (maybe 
better, because the two “screens” don’t have to be the same size anymore), but 
I haven’t had a chance to try one out yet.

> Xcode is really amazing: when I regenerate the project in a terminal, there 
> is no need to close and reopen xcode. Xcode will collapse the navigator, but 
> otherwise it just refreshes with the new content. Its quite neat to work this 
> way. The only two drawbacks that I have detected so far is that I need to 
> “clean” more in Xcode, and that the old project settings are overwritten, 
> thus if you do a lot of tweaking of the build settings this might not work 
> out all that well.

Yeah, if Xcode were open-source, I’d be working on SwiftPM integration. Hmm… 
Maybe SwiftPM can detect if a .xcodeproj file already exists and copy any 
custom settings from there before writing the new one? That might not be too 
hard, depending on how complicated those files are.

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

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

[Zhao Xin via swift-users]

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

}

}


let fooSetA:Set = [Foo(8), Foo(9)]

let fooSetB:Set = [Foo(9), Foo(10)]

let fooResultC = fooSetA.intersection(fooSetB) // {{value 9}}

let fooResultD = fooSetA.subtracting(fooSetB) // {{value 8}}



class Bar:NSObject {

let value:Int



override public var hashValue: Int { return value }

public static func ==(lhs: Bar, rhs: Bar) -> Bool {

return lhs.value == rhs.value

}



init(_ value:Int) {

self.value = value

}

}


let barSetA:Set = [Bar(8), Bar(9)]

let barSetB:Set = [Bar(9), Bar(10)]

let barResultC = barSetA.intersection(barSetB) // Set([])

let barResultD = barSetA.subtracting(barSetB) // {{NSObject, value 9},
{NSObject, value 8}}


Behaviors of `func intersection(Set)` and `func
subtracting(Set)` were different between normal Swift class
and NSObject subclasses. I had thought they should be the same. It seemed
that Set relied on addresses of NSObject instances instead of
their hashValues. That made the Set useless.

Swift version: 3.1 (swiftlang-802.0.48 clang-802.0.48)
Xcode 8.3 (8E162)

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

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

[Mohit Athwani via swift-users]

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 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 Foundation directory
> to build it, and if you need to modify the build scripts (for example
> including additional files) you can run ./configure --reconfigure
>
> On Mar 28, 2017, at 12:28 PM, Mohit Athwani via swift-users <
> swift-users@swift.org> wrote:
>
> 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
> ___
> 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] Foundation: build.ninja No such file or directory

[Mohit Athwani via swift-users]

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-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Philippe Hausler via swift-users]

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 Foundation directory to 
build it, and if you need to modify the build scripts (for example including 
additional files) you can run ./configure --reconfigure

> On Mar 28, 2017, at 12:28 PM, Mohit Athwani via swift-users 
>  wrote:
> 
> 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
> ___
> 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] Improving compilation times?

[piotr gorzelany via swift-users]

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 one
or two files it seems that there is only incremental compilation.

wt., 28 mar 2017 o 20:58 użytkownik Jon Shier  napisał:

> 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 <
> swift-users@swift.org> wrote:
>
> 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?
>
>
> Wiadomość napisana przez Mark Lacey via swift-users 
> w dniu 23.03.2017, o godz. 18:06:
>
>
> On Mar 23, 2017, at 10:02 AM, piotr gorzelany 
> wrote:
>
> I tried using it with the latest Xcode release (version 8.2).
>
>
> That was released prior to the addition of the new option. Recent snapshot
> builds from https://swift.org/download/#snapshots as well as the more
> recent Xcode 8.3 betas have it.
>
> Mark
>
> W dniu czw., 23.03.2017 o 17:57 Mark Lacey 
> napisał(a):
>
> On Mar 23, 2017, at 1:58 AM, piotr gorzelany 
> wrote:
>
> Hi Mark,
>
> Thanks for the answer, its great to know that somebody is working on it!
>
> I tried to add the -Xfrontend -debug-time-expression-type-checking in
> Xcode in the Other Swift Flags section but that gives me an error when
> compiling
>
> :0: error: unknown argument:
> '-debug-time-expression-type-checking'
>
> Should I rather compile it on the command line using this option?
>
>
> I added this to the compiler within the last couple months so you need to
> be using a recent build in order to use this command-line option. Where did
> the compiler that you tried it with come from?
>
> Mark
>
>
> Regards,
> Piotr
>
> czw., 23 mar 2017 o 08:54 użytkownik Mark Lacey via swift-users <
> swift-users@swift.org> napisał:
>
>
> > On Mar 23, 2017, at 12:32 AM, Rien via swift-users <
> swift-users@swift.org> wrote:
> >
> >
> >> On 23 Mar 2017, at 08:27, David Hart  wrote:
> >>
> >> Yes, it's best to avoid concatenating strings with +. Not only for
> performance reasons, but it's also less readable than string interpolation:
> >>
> >> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ??
> "?")\n”
> >
> > Concatenation may cause the increase, but this solved it too:
> >
> >let (clientIpOrNil, serviceOrNil) =
> sockaddrDescription(info.pointee.ai_addr)
> >let clientIp = clientIpOrNil ?? "?"
> >let service = serviceOrNil ?? "?"
> >str += "No: \(count), HostIp: " + clientIp + " at port: " +
> service + "\n”
>
> To make a long story short, expressions combining the results of
> nil-coalescing with other operators tend to be very slow to type check at
> the moment. I’m working on fixing this (really the more general issue as it
> is not specific to ?? but I’ve seen several bug reports that involve that
> operator).
>
> I added another command-line option to help track issues like this down
> (at the expression level, rather than function level):
>   -Xfrontend -debug-time-expression-type-checking
>
> If you use that you’ll see a line for every expression that is
> type-checked, with source location information, and the time to type check
> the expression. In some cases we may not have valid source information (I
> believe this generally happens for things the compiler synthesizes rather
> than user code), and you’ll see ‘’ rather than the
> file/line/column info.
>
> Mark
>
>
> >
> > Regards,
> > Rien.
> >
> >
> >>
> >> On 23 Mar 2017, at 08:11, Rien via swift-users 
> wrote:
> >>
> >>> Thanks for that link, used it to track down the worst compile time
> offender:
> >>>
> >>> This piece of code:
> >>>
> >>> public func logAddrInfoIPAddresses(_ infoPtr:
> UnsafeMutablePointer) -> String {
> >>>
> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
> >>>   var count: Int = 0
> >>>   var info: UnsafeMutablePointer = infoPtr
> >>>   var str: String = ""
> >>>
> >>>   while info != addrInfoNil {
> >>>
> >>>   let (clientIp, service) =
> sockaddrDescription(info.pointee.ai_addr)
> >>>   str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port:
> " + (service ?? "?") + "\n"
> >>>   count += 1
> >>>   info = info.pointee.ai_next
> >>>   }
> >>>   return str
> >>> }
> >>>
> >>> Took 38 seconds to compile.
> >>>
> >>> Removing the “str” assignment:
> >>>
> >>> public func logAddrInfoIPAddresses(_ infoPtr:
> 

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

[Mohit Athwani via swift-users]

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___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[Rick Aurbach via swift-users]

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(animated)
FontSelectorDialog.chooser.textChooserType = .text
}

< . . . >
}

BY THE WAY — I didn’t think to mention this previously, but the “leaking” code 
is in a framework and I put the suggested test code in the same framework.

Using Xcode 8.3:

(1) Running Simulator for iPhone 7+ (10.3), profiling the code, neither your 
suggested test code NOR the original code shows a leak in the Leaks Instrument.

(2) Running on an iPad Air 2 (10.2), profiling the code, your suggested test 
code does NOT show a leak, but the original code DOES. (The stack trace for the 
leak point is at the bottom of this email.)

I haven’t taken the next step of attempting to build a simple example to see if 
I can duplicate the problem in a simple project. I’d like to pursue this 
because it is increasingly looking like a “not my” bug, and I’d like to prevent 
others from spending as much time on this issue as I have already.

Cheers,

Rick Aurbach


> On Mar 28, 2017, at 4:14 AM, Alex Blewitt  wrote:
> 
>> 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 can create a simple, artificial example. If it 
>> also reports a leak, then I could try looping it. I’ll look into it in the 
>> morning.
> 
> You could try doing something like:
> 
> static let choser:ColorChoser = ColorChoser()
> choser.textChoserType = .text
> 
> Run that in Xcode and see if it shows a leak.
> 
> Alex


   0 libsystem_malloc.dylib malloc_zone_malloc
   1 libsystem_malloc.dylib malloc
   2 libswiftCore.dylib swift_slowAlloc
   3 libswiftCore.dylib _swift_allocObject_
   4 libswiftCore.dylib _swift_allocObject_
   5 RLAFontSelector specialized RLAFontSelectorDialog.prepare(for : 
UIStoryboardSegue, sender : Any?) -> () 
/Users/rlaurb/Projects/RLAFontSelector/Sources/RLAFontSelectorDialog.swift:0
   6 RLAFontSelector RLAFontSelectorDialog.prepare(for : UIStoryboardSegue, 
sender : Any?) -> () 
/Users/rlaurb/Projects/RLAFontSelector/Sources/RLAFontSelectorDialog.swift:0
   7 RLAFontSelector @objc RLAFontSelectorDialog.prepare(for : 
UIStoryboardSegue, sender : Any?) -> () 
/Users/rlaurb/Projects/RLAFontSelector/Sources/RLAFontSelectorDialog.swift:0
   8 UIKit -[UIStoryboardSegueTemplate 
_performWithDestinationViewController:sender:]
   9 UIKit -[UIStoryboardSegueTemplate _perform:]
  10 UIKit -[UIStoryboardSegueTemplate perform:]
  11 UIKit -[UITableView 
_selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:]
  12 UIKit -[UITableView _userSelectRowAtPendingSelectionIndexPath:]
  13 UIKit _runAfterCACommitDeferredBlocks
  14 UIKit _cleanUpAfterCAFlushAndRunDeferredBlocks
  15 UIKit _afterCACommitHandler
  16 CoreFoundation 
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
  17 CoreFoundation __CFRunLoopDoObservers
  18 CoreFoundation __CFRunLoopRun
  19 CoreFoundation CFRunLoopRunSpecific
  20 GraphicsServices GSEventRunModal
  21 UIKit -[UIApplication _run]
  22 UIKit UIApplicationMain
  23 PoetsCorner main 
/Users/rlaurb/Projects/PoetsCorner/PoetsCorner/SettingsController.swift:13
  24 libdyld.dylib start

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

Re: [swift-users] Improving compilation times?

[Jon Shier via swift-users]

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_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?
> 
> 
>>> Wiadomość napisana przez Mark Lacey via swift-users  
>>> w dniu 23.03.2017, o godz. 18:06:
>>> 
>>> 
>>> On Mar 23, 2017, at 10:02 AM, piotr gorzelany  
>>> wrote:
>>> 
>>> I tried using it with the latest Xcode release (version 8.2).
>> 
>> That was released prior to the addition of the new option. Recent snapshot 
>> builds from https://swift.org/download/#snapshots as well as the more recent 
>> Xcode 8.3 betas have it.
>> 
>> Mark
>> 
>>> W dniu czw., 23.03.2017 o 17:57 Mark Lacey  
>>> napisał(a):
> On Mar 23, 2017, at 1:58 AM, piotr gorzelany  
> wrote:
> 
> Hi Mark,
> 
> Thanks for the answer, its great to know that somebody is working on it!
> 
> I tried to add the -Xfrontend -debug-time-expression-type-checking in 
> Xcode in the Other Swift Flags section but that gives me an error when 
> compiling 
> 
> :0: error: unknown argument: 
> '-debug-time-expression-type-checking'
> 
> Should I rather compile it on the command line using this option?
 
 I added this to the compiler within the last couple months so you need to 
 be using a recent build in order to use this command-line option. Where 
 did the compiler that you tried it with come from?
 
 Mark
 
> 
> Regards,
> Piotr
> 
> czw., 23 mar 2017 o 08:54 użytkownik Mark Lacey via swift-users 
>  napisał:
> 
> > On Mar 23, 2017, at 12:32 AM, Rien via swift-users 
> >  wrote:
> >
> >
> >> On 23 Mar 2017, at 08:27, David Hart  wrote:
> >>
> >> Yes, it's best to avoid concatenating strings with +. Not only for 
> >> performance reasons, but it's also less readable than string 
> >> interpolation:
> >>
> >> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ?? 
> >> "?")\n”
> >
> > Concatenation may cause the increase, but this solved it too:
> >
> >let (clientIpOrNil, serviceOrNil) = 
> > sockaddrDescription(info.pointee.ai_addr)
> >let clientIp = clientIpOrNil ?? "?"
> >let service = serviceOrNil ?? "?"
> >str += "No: \(count), HostIp: " + clientIp + " at port: " + 
> > service + "\n”
> 
> To make a long story short, expressions combining the results of 
> nil-coalescing with other operators tend to be very slow to type check at 
> the moment. I’m working on fixing this (really the more general issue as 
> it is not specific to ?? but I’ve seen several bug reports that involve 
> that operator).
> 
> I added another command-line option to help track issues like this down 
> (at the expression level, rather than function level):
>   -Xfrontend -debug-time-expression-type-checking
> 
> If you use that you’ll see a line for every expression that is 
> type-checked, with source location information, and the time to type 
> check the expression. In some cases we may not have valid source 
> information (I believe this generally happens for things the compiler 
> synthesizes rather than user code), and you’ll see ‘’ rather 
> than the file/line/column info.
> 
> Mark
> 
> 
> >
> > Regards,
> > Rien.
> >
> >
> >>
> >> On 23 Mar 2017, at 08:11, Rien via swift-users  
> >> wrote:
> >>
> >>> Thanks for that link, used it to track down the worst compile time 
> >>> offender:
> >>>
> >>> This piece of code:
> >>>
> >>> public func logAddrInfoIPAddresses(_ infoPtr: 
> >>> UnsafeMutablePointer) -> String {
> >>>
> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
> >>>   var count: Int = 0
> >>>   var info: UnsafeMutablePointer = infoPtr
> >>>   var str: String = ""
> >>>
> >>>   while info != addrInfoNil {
> >>>
> >>>   let (clientIp, service) = 
> >>> sockaddrDescription(info.pointee.ai_addr)
> >>>   str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at 
> >>> port: " + (service ?? "?") + "\n"
> >>>   count += 1
> >>>   info = info.pointee.ai_next
> >>>   }
> >>>   return str
> >>> }
> >>>
> >>> Took 38 seconds to compile.
> >>>
> >>> Removing 

Re: [swift-users] Improving compilation times?

[Bartłomiej Nowak via swift-users]

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?


> Wiadomość napisana przez Mark Lacey via swift-users  w 
> dniu 23.03.2017, o godz. 18:06:
> 
> 
>> On Mar 23, 2017, at 10:02 AM, piotr gorzelany > > wrote:
>> 
>> I tried using it with the latest Xcode release (version 8.2).
> 
> That was released prior to the addition of the new option. Recent snapshot 
> builds from https://swift.org/download/#snapshots 
>  as well as the more recent Xcode 8.3 
> betas have it.
> 
> Mark
> 
>> W dniu czw., 23.03.2017 o 17:57 Mark Lacey > > napisał(a):
>>> On Mar 23, 2017, at 1:58 AM, piotr gorzelany >> > wrote:
>>> 
>>> Hi Mark,
>>> 
>>> Thanks for the answer, its great to know that somebody is working on it!
>>> 
>>> I tried to add the -Xfrontend -debug-time-expression-type-checking in Xcode 
>>> in the Other Swift Flags section but that gives me an error when compiling 
>>> 
>>> :0: error: unknown argument: '-debug-time-expression-type-checking'
>>> 
>>> Should I rather compile it on the command line using this option?
>> 
>> I added this to the compiler within the last couple months so you need to be 
>> using a recent build in order to use this command-line option. Where did the 
>> compiler that you tried it with come from?
>> 
>> Mark
>> 
>>> 
>>> Regards,
>>> Piotr
>>> 
>>> czw., 23 mar 2017 o 08:54 użytkownik Mark Lacey via swift-users 
>>> > napisał:
>>> 
>>> > On Mar 23, 2017, at 12:32 AM, Rien via swift-users >> > > wrote:
>>> >
>>> >
>>> >> On 23 Mar 2017, at 08:27, David Hart >> >> > wrote:
>>> >>
>>> >> Yes, it's best to avoid concatenating strings with +. Not only for 
>>> >> performance reasons, but it's also less readable than string 
>>> >> interpolation:
>>> >>
>>> >> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ?? 
>>> >> "?")\n”
>>> >
>>> > Concatenation may cause the increase, but this solved it too:
>>> >
>>> >let (clientIpOrNil, serviceOrNil) = 
>>> > sockaddrDescription(info.pointee.ai_addr)
>>> >let clientIp = clientIpOrNil ?? "?"
>>> >let service = serviceOrNil ?? "?"
>>> >str += "No: \(count), HostIp: " + clientIp + " at port: " + 
>>> > service + "\n”
>>> 
>>> To make a long story short, expressions combining the results of 
>>> nil-coalescing with other operators tend to be very slow to type check at 
>>> the moment. I’m working on fixing this (really the more general issue as it 
>>> is not specific to ?? but I’ve seen several bug reports that involve that 
>>> operator).
>>> 
>>> I added another command-line option to help track issues like this down (at 
>>> the expression level, rather than function level):
>>>   -Xfrontend -debug-time-expression-type-checking
>>> 
>>> If you use that you’ll see a line for every expression that is 
>>> type-checked, with source location information, and the time to type check 
>>> the expression. In some cases we may not have valid source information (I 
>>> believe this generally happens for things the compiler synthesizes rather 
>>> than user code), and you’ll see ‘’ rather than the 
>>> file/line/column info.
>>> 
>>> Mark
>>> 
>>> 
>>> >
>>> > Regards,
>>> > Rien.
>>> >
>>> >
>>> >>
>>> >> On 23 Mar 2017, at 08:11, Rien via swift-users >> >> > wrote:
>>> >>
>>> >>> Thanks for that link, used it to track down the worst compile time 
>>> >>> offender:
>>> >>>
>>> >>> This piece of code:
>>> >>>
>>> >>> public func logAddrInfoIPAddresses(_ infoPtr: 
>>> >>> UnsafeMutablePointer) -> String {
>>> >>>
>>> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
>>> >>>   var count: Int = 0
>>> >>>   var info: UnsafeMutablePointer = infoPtr
>>> >>>   var str: String = ""
>>> >>>
>>> >>>   while info != addrInfoNil {
>>> >>>
>>> >>>   let (clientIp, service) = 
>>> >>> sockaddrDescription(info.pointee.ai_addr)
>>> >>>   str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: 
>>> >>> " + (service ?? "?") + "\n"
>>> >>>   count += 1
>>> >>>   info = info.pointee.ai_next
>>> >>>   }
>>> >>>   return str
>>> >>> }
>>> >>>
>>> >>> Took 38 seconds to compile.
>>> >>>
>>> >>> Removing the “str” assignment:
>>> >>>
>>> >>> public func logAddrInfoIPAddresses(_ infoPtr: 
>>> >>> UnsafeMutablePointer) -> String {
>>> >>>
>>> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
>>> >>>   var count: Int = 0
>>> 

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

[Michael Ilseman via swift-users]

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 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 that have 
> to be implemented to conform to the protocol.
> 
> Here you can find the other ones:
> 
> /// Describes an error that may be recoverable by presenting several
> /// potential recovery options to the user.
> public protocol RecoverableError : Error {
> 
> /// Provides a set of possible recovery options to present to the user.
> public var recoveryOptions: [String] { get }
> 
> /// Attempt to recover from this error when the user selected the
> /// option at the given index. This routine must call handler and
> /// indicate whether recovery was successful (or not).
> ///
> /// This entry point is used for recovery of errors handled at a
> /// "document" granularity, that do not affect the entire
> /// application.
> public func attemptRecovery(optionIndex recoveryOptionIndex: Int, 
> resultHandler handler: (Bool) -> Swift.Void)
> 
> /// Attempt to recover from this error when the user selected the
> /// option at the given index. Returns true to indicate
> /// successful recovery, and false otherwise.
> ///
> /// This entry point is used for recovery of errors handled at
> /// the "application" granularity, where nothing else in the
> /// application can proceed until the attempted error recovery
> /// completes.
> public func attemptRecovery(optionIndex recoveryOptionIndex: Int) -> Bool
> }
> 
> As you can see, there are two attemptRecovery methods. In my mind the first 
> one was meant to be used for asynchronous operations, where you run some 
> recovering code in background and then report its result back to the caller.
> 
> The problem is that the handler is not marked as @escaping and as such it can 
> only be used inside the body of attemptRecovery. I was wondering if this was 
> an oversight from the stdlib team or if this was a deliberate design decision.
> 
> I just saw that the method is still not marked as @escaping in master 
> (https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/NSError.swift#L105
>  
> ),
>  so I’d like to know what its intended use case is, since the obvious one 
> (asynchronous recovery) is prevented by the missing annotation.
> 
> Thanks,
> Elia Cereda
> 
>> Il giorno 28 mar 2017, alle ore 17:33, Dennis Weissmann 
>> > ha scritto:
>> 
>> Hey Elia,
>> 
>> I'm currently on mobile and don't really know what you're talking about 
>> (what is RecoverableError?) but you say it's a block, and if the closure is 
>> optional, it is @escaping by default.
>> 
>> Did you see 
>> https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160905/003185.html
>>  
>> 
>> 
>> - Dennis
>> 
>> Sent from my iPhone
>> 
>> On 23. Mar 2017, at 10:07 AM, Elia Cereda via swift-users 
>> > wrote:
>> 
>>> I'd like to bump this issue, since it has been some time and it hasn't been 
>>> addressed.
>>> 
>>> Thanks,
>>> Elia Cereda
>>> 
>>> Il giorno 03 mar 2017, alle ore 21:33, Elia Cereda >> > ha scritto:
>>> 
 I’m wondering why the resultHandler block on 
 RecoverableError.attemptRecovery(optionIndex, resultHandler:) is not 
 marked @escaping?
 
 I’m trying to invoke some recovering code that executes asynchronously, 
 then reports if it was successful or not and I thought that this was the 
 right strategy. As far as I can tell, without @escaping that method loses 
 all it’s purpose and becomes essentially equivalent to 
 attemptRecovery(optionIndex:).
 
 So, I’d like to ask.
 1. Is it a bug or that method is non-escaping on purpose?
 2. If it is a bug, is there a workaround that can be applied pending a fix 
 in a future version of Swift?
 3. If it was a deliberate decision, what's the supported method of 
 asynchronously invoking error recovery code?
 
 Seeing that this wasn’t changed in Xcode 8.3b2, I think it unlikely that 
 this was an oversight.
 
 Thanks,
 Elia Cereda
 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org 
>>> 

Re: [swift-users] Importing C system libraries

[Michael Ilseman via swift-users]

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
// … use libGit2


Read more about how to write a more appropriate module.map file for your 
purposes at https://clang.llvm.org/docs/Modules.html 
. For example, you might be able to 
define link flags inside the module.map, use umbrella directories, submodules, 
etc.



> On Mar 28, 2017, at 6:27 AM, Kelvin Ma  wrote:
> 
> 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 part.
> 
> 
> > On Mar 26, 2017, at 3:20 PM, Kelvin Ma via swift-users 
> > > wrote:
> >
> > Idk if this has been asked before, but is there a way to import C libraries 
> > into a Swift project without creating a local git repo? Preferably 
> > something similar to C where you can just `#include` headers and then 
> > specify the link flags (in Package.swift?)
> >
> > It’s getting very cumbersome to make a bunch of empty git repos just to use 
> > libglfw or libcairo.
> > ___
> > 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] Asynchronous error recovering with RecoverableError

[Elia Cereda via swift-users]

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 that have to 
be implemented to conform to the protocol.

Here you can find the other ones:

/// Describes an error that may be recoverable by presenting several
/// potential recovery options to the user.
public protocol RecoverableError : Error {

/// Provides a set of possible recovery options to present to the user.
public var recoveryOptions: [String] { get }

/// Attempt to recover from this error when the user selected the
/// option at the given index. This routine must call handler and
/// indicate whether recovery was successful (or not).
///
/// This entry point is used for recovery of errors handled at a
/// "document" granularity, that do not affect the entire
/// application.
public func attemptRecovery(optionIndex recoveryOptionIndex: Int, 
resultHandler handler: (Bool) -> Swift.Void)

/// Attempt to recover from this error when the user selected the
/// option at the given index. Returns true to indicate
/// successful recovery, and false otherwise.
///
/// This entry point is used for recovery of errors handled at
/// the "application" granularity, where nothing else in the
/// application can proceed until the attempted error recovery
/// completes.
public func attemptRecovery(optionIndex recoveryOptionIndex: Int) -> Bool
}

As you can see, there are two attemptRecovery methods. In my mind the first one 
was meant to be used for asynchronous operations, where you run some recovering 
code in background and then report its result back to the caller.

The problem is that the handler is not marked as @escaping and as such it can 
only be used inside the body of attemptRecovery. I was wondering if this was an 
oversight from the stdlib team or if this was a deliberate design decision.

I just saw that the method is still not marked as @escaping in master 
(https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/NSError.swift#L105
 
),
 so I’d like to know what its intended use case is, since the obvious one 
(asynchronous recovery) is prevented by the missing annotation.

Thanks,
Elia Cereda

> Il giorno 28 mar 2017, alle ore 17:33, Dennis Weissmann 
>  ha scritto:
> 
> Hey Elia,
> 
> I'm currently on mobile and don't really know what you're talking about (what 
> is RecoverableError?) but you say it's a block, and if the closure is 
> optional, it is @escaping by default.
> 
> Did you see 
> https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160905/003185.html
>  
> 
> 
> - Dennis
> 
> Sent from my iPhone
> 
> On 23. Mar 2017, at 10:07 AM, Elia Cereda via swift-users 
> > wrote:
> 
>> I'd like to bump this issue, since it has been some time and it hasn't been 
>> addressed.
>> 
>> Thanks,
>> Elia Cereda
>> 
>> Il giorno 03 mar 2017, alle ore 21:33, Elia Cereda > > ha scritto:
>> 
>>> I’m wondering why the resultHandler block on 
>>> RecoverableError.attemptRecovery(optionIndex, resultHandler:) is not marked 
>>> @escaping?
>>> 
>>> I’m trying to invoke some recovering code that executes asynchronously, 
>>> then reports if it was successful or not and I thought that this was the 
>>> right strategy. As far as I can tell, without @escaping that method loses 
>>> all it’s purpose and becomes essentially equivalent to 
>>> attemptRecovery(optionIndex:).
>>> 
>>> So, I’d like to ask.
>>> 1. Is it a bug or that method is non-escaping on purpose?
>>> 2. If it is a bug, is there a workaround that can be applied pending a fix 
>>> in a future version of Swift?
>>> 3. If it was a deliberate decision, what's the supported method of 
>>> asynchronously invoking error recovery code?
>>> 
>>> Seeing that this wasn’t changed in Xcode 8.3b2, I think it unlikely that 
>>> this was an oversight.
>>> 
>>> Thanks,
>>> Elia Cereda
>>> 
>> ___
>> 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 C system libraries

[Kelvin Ma via swift-users]

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 part.
>
>
> > On Mar 26, 2017, at 3:20 PM, Kelvin Ma via swift-users <
> swift-users@swift.org> wrote:
> >
> > Idk if this has been asked before, but is there a way to import C
> libraries into a Swift project without creating a local git repo?
> Preferably something similar to C where you can just `#include` headers and
> then specify the link flags (in Package.swift?)
> >
> > It’s getting very cumbersome to make a bunch of empty git repos just to
> use libglfw or libcairo.
> > ___
> > 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 C system libraries

[Kelvin Ma via swift-users]

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.
>
> > On Mar 27, 2017, at 2:10 PM, Jan Neumüller  wrote:
> >
> > Is it just me, or is Swift moving to much in a command line direction
> since the open sourcing? I feel being left behind as an Xcode user...
> >
> > Jan
> >
> >> On 27 Mar 2017, at 22:59, Michael Ilseman via swift-users <
> swift-users@swift.org> 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 part.
> >>
> >>
> >>> On Mar 26, 2017, at 3:20 PM, Kelvin Ma via swift-users <
> swift-users@swift.org> wrote:
> >>>
> >>> Idk if this has been asked before, but is there a way to import C
> libraries into a Swift project without creating a local git repo?
> Preferably something similar to C where you can just `#include` headers and
> then specify the link flags (in Package.swift?)
> >>>
> >>> It’s getting very cumbersome to make a bunch of empty git repos just
> to use libglfw or libcairo.
> >>> ___
> >>> 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] Why does this leak?

[Alex Blewitt via swift-users]

> 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 can create a simple, artificial example. If it 
> also reports a leak, then I could try looping it. I’ll look into it in the 
> morning.

You could try doing something like:

static let choser:ColorChoser = ColorChoser()
choser.textChoserType = .text

Run that in Xcode and see if it shows a leak.

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

Re: [swift-users] Importing C system libraries

[Rien via swift-users]

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 productivity.

I use a large monitor and have two terminal windows open at all times on the 
left side, and Xcode open on the right. Two monitors would be even better (I 
think).
Xcode is really amazing: when I regenerate the project in a terminal, there is 
no need to close and reopen xcode. Xcode will collapse the navigator, but 
otherwise it just refreshes with the new content. Its quite neat to work this 
way. The only two drawbacks that I have detected so far is that I need to 
“clean” more in Xcode, and that the old project settings are overwritten, thus 
if you do a lot of tweaking of the build settings this might not work out all 
that well.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 27 Mar 2017, at 23:10, Jan Neumüller via swift-users 
>  wrote:
> 
> Is it just me, or is Swift moving to much in a command line direction since 
> the open sourcing? I feel being left behind as an Xcode user...
> 
> Jan
> 
>> On 27 Mar 2017, at 22:59, Michael Ilseman via swift-users 
>>  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 part.
>> 
>> 
>>> On Mar 26, 2017, at 3:20 PM, Kelvin Ma via swift-users 
>>>  wrote:
>>> 
>>> Idk if this has been asked before, but is there a way to import C libraries 
>>> into a Swift project without creating a local git repo? Preferably 
>>> something similar to C where you can just `#include` headers and then 
>>> specify the link flags (in Package.swift?) 
>>> 
>>> It’s getting very cumbersome to make a bunch of empty git repos just to use 
>>> libglfw or libcairo.
>>> ___
>>> 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