Re: [swift-users] Swift and Xcode along with Playgrounds is full of bugs

[Chris Lattner via swift-users]

On Sep 13, 2016, at 5:34 PM, Shyamal Chandra  wrote:
> Hi Chris,
> 
> Here is a forum question that I posted a while back.  The latest post says to 
> file a bug under the bug report.  
> 
> Here's the post:
> 
> https://forums.developer.apple.com/thread/61953 
>  (Playgrounds error)

Thanks for the link.  Contrary to your claims, it appears that you promptly got 
a response from an Apple employee, and it appears that you didn’t follow his 
instructions to file a radar in bugreporter.apple.com.

Now that Xcode 8 has shipped to the Mac App Store today, I’d suggest you 
download that and try it.  There are a number of bugs that are fixed between 
beta 6 and the final release, and that may include this one.

> I was doing something "simple" in Playgrounds and my version of Playgrounds 
> doesn't function properly because it is emitting an error when I write 
> bug-free code.  Why is Playgrounds so flaky?  Sometimes, it shows the output 
> on the right side; sometime, it doesn’t.

Two simple and obvious answers come to mind: you are running advertised-as-beta 
software, and even shipping software does have bugs.

> I have had mixed success with the bug reporter tool from Apple; most of the 
> time, they ask for the system diagnostics and then, tell you to update your 
> version.  Sometimes, they just close the issue and nothing happens.


I understand that you claim to have had problems with 
Radar/bugreporter.apple.com, but again I can see no evidence of you ever filing 
a bug in it (and you haven’t provided me any radar numbers to cross reference), 
so there isn’t much I can do to help you.  Needless to say, we do actually need 
the system diagnostics in order to reproduce issues like this, as you found on 
the forum, your issue doesn’t reproduce trivially for other folks.


Finally, as others have pointed out, your approach on this thread hasn’t been 
particularly constructive.  Despite your apparent expectation, Apple has not 
signed up to fix any and every bug reported against Swift.  That said, we all 
want to build a strong community, and if you are interested in working in a 
helpful and productive way we would love for you to be part of that community.  
On the other hand, if you find that Swift on Linux isn’t ready for you today 
and that you don’t want to invest effort in it, then perhaps it is best for you 
to come back at some point later in the future.

Thanks,

-Chris

> 
> 
> Thanks!
> 
> Best,
> 
> Shyamal Chandra
> shyam...@gmail.com 
> Linkedin: http://www.linkedin.com/in/shyamalc 
> 
> Phone: 620-719-9064
> 
> On Tue, Sep 13, 2016 at 7:02 PM, Chris Lattner  > wrote:
> On Sep 12, 2016, at 3:03 PM, Shyamal Chandra via swift-users 
> > wrote:
> > Hope you are doing well!
> >
> > Swift is very volatile language that keeps on changing with every new 
> > version of Xcode.  When you are trying to run old code with different 
> > syntax, you run into problems because the code is no longer compatible.  
> > Instead of moving onto Swift 3, 4, and 5 (with different syntax), why don't 
> > you standardize the library and language operations and functions for the 
> > different package and frameworks included with Xcode
> 
> The subject line of this message seems like it is intended to be provocative, 
> not helpful.
> 
> Despite that, you’ll be happy to know that the goal of Swift 4 is to be 
> source compatible with Swift 3, so the concerns that you are complaining 
> about are historic, not future problems.
> 
> > because I have already submitted multiple bugs to the bug report that are 
> > with the official release of Xcode and I am very disappointed with the 
> > software quality.
> 
> I don’t see any radars filed by you in the system, but perhaps they are just 
> under a different name.  In any case, thank you for filing bugs, we do read 
> and care about them!  Please send me the radar numbers (off list if you 
> prefer) and I’ll take a look.
> 
> -Chris
> 
> 

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

Re: [swift-users] Swift and Xcode along with Playgrounds is full of bugs

[Austin Zheng via swift-users]

Hi Shyamal,

Please share with us the SLA you signed with Apple that guarantees you any 
level of paid support with regards to Swift, or alternatively an invoice that 
shows us how much you paid for a license to use the Linux port of Swift.

Best regards,
Austin

> On Sep 13, 2016, at 7:24 PM, Shyamal Chandra via swift-users 
>  wrote:
> 
> Hi Shawn,
> 
> Could you give me examples of what I said was clearly "unprofessional"?  Two 
> months for a bug because open source is "do it yourself".  This sounds like a 
> crappy support team by a large multinational company that open sources 
> non-functional Linux ports of its language.  I gave clear examples and bugs 
> so I don't understand why you are getting defensive and hammering me with the 
> "unprofessional" word.  First, address the issues and the bugs; I gave you 
> clear examples and you circumvent those issues and flag the post because you 
> don't want to confront that the tooling is buggy and flaky.
> 
> I believe that a company of Apple's stature is unprofessional when they 
> deliver buggy code to their customers that they pay money for.  Before you 
> respond to this message, please address the bugs that I hyperlinked and the 
> forum question problem.  You are wasting my time.
> 
> Thanks!
> 
> Best,
> 
> Shyamal Chandra
> shyam...@gmail.com 
> Linkedin: http://www.linkedin.com/in/shyamalc 
> 
> Phone: 620-719-9064
> 
> On Tue, Sep 13, 2016 at 9:16 PM, Shawn Erickson  > wrote:
> You message are really coming across with an unprofessional tone. I 
> understand you are frustrated but folks inside and outside of Apple have been 
> working their butts off and frankly deserve a little more civility.
> 
> Anyway, the Linux side of things is very much an open source - do it yourself 
> - type of thing at this time. I am sure folks would love to have the issues 
> and short coming addressed but need folks to step forward.
> 
> If you would like to talk specifics about swift issues you are having a fair 
> number of folks are on this list and possibly could help.
> 
> Also note Apple folks are likely a little burned out right now with all of 
> the crazy work closing out - as best they could - on Swift 3 and Xcode 8, 
> etc. so they may not be the quickest to respond.
> 
> -Shawn
> On Tue, Sep 13, 2016 at 6:53 PM Shyamal Chandra via swift-users 
> > wrote:
> I am not arguing; I am bringing up defect in the Apple way of handling bugs 
> for Swift, Xcode, and Playgrounds.  Am I supposed to wait for eternity?
> 
> On Tuesday, September 13, 2016, Jens Alfke  > wrote:
> 
>> On Sep 13, 2016, at 6:27 PM, Shyamal Chandra > wrote:
>> 
>> Do you really think that is a viable option again?
> 
> No, you’re right. Reporting bugs is clearly the least viable option, except 
> for all the other options* (like arguing on mailing lists.)
> 
> —Jens
> 
> * With apologies to Winston Churchill
> 
> 
> -- 
> Sent from Gmail Mobile
> ___
> 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] @escaping may only be applied to parameters of function type

[Shawn Erickson via swift-users]

I am in the process of updating to Xcode 8 release so I can't confirm at
the moment but I am fairly sure I hit a situation with being asked to
implement a func from a protocol that got autocompleted with @escape nested
as shown. It would then of course complain that wasn't valid. If I fixed it
I don't think it was considered being implemented (it could only be an
issue as noted in my prior thread related to default implementation not
being picked up).

I will start a discussion about @escaping on the evolution list (hopefully
soon). The main issue I see – beyond quirks like this – is that the
proposal stated that closures would become noescape by default. I had
existing code that applied @noescape against optional closures as well as
tuples with closures, etc. which was happy and appeared to honor @noescape.
I had expected closures in all "constructs" to be considered noescape after
this change (what I got from reading the proposal) however in some
situations they are considered escaping now when in fact in the past
@noescape was able to be applied to state otherwise. It is possible that
@noescape wasn't actually doing anything in those cases but it seemed like
it was working to me.

So now I have code that I can't make work since it was meant to be noescape
yet it is now considered escaping implicitly. If I try to fix this code I
get complaints about things expected to escape and/or things needed to not
escape (hard to explain with examples). I can likely rework the code to get
it working again but expect to lose some of the desired implementation.

-Shawn

On Tue, Sep 13, 2016 at 8:16 PM Michael Ilseman  wrote:

>
> > On Sep 13, 2016, at 8:14 PM, Rick Mann  wrote:
> >
> > But the Apple declaration (accessible via Xcode) of the method it's
> based on looks like this:
> >
> > open func enumerator(at url: URL,
> >includingPropertiesForKeys keys: [URLResourceKey]?,
> >options mask: FileManager.DirectoryEnumerationOptions = [],
> >errorHandler handler: (@escaping (URL, Error) -> Bool)? = nil)
> >-> FileManager.DirectoryEnumerator?
> >
> > handler is optional, but has @escaping. Is this an artifact of how Xcode
> presents system header files?
> >
>
> That’s certainly funky. Might be that or a bug in the AST printer.
>
> >
> >> On Sep 13, 2016, at 20:11 , Michael Ilseman  wrote:
> >>
> >> TL;DR: The optional is already escaping, due to the fact that “T?" is
> sugar for Optional, and the noescape-by-default rule only applies to
> types in immediate parameter position. Current Swift master has much better
> diagnostics for this case.
> >>
> >> There is not currently a general solution involving escapability of
> closure types used a generic parameters or tuple members, though such a
> thing would be useful in Swift 4.
> >>
> >>> On Sep 13, 2016, at 7:42 PM, Shawn Erickson via swift-users <
> swift-users@swift.org> wrote:
> >>>
> >>> The following is the earlier thread I was talking about.
> >>>
> >>> [swift-users] Swift 3 (Xcode 8 GM) issue with @escaping
> >>>
> >>> -Shawn
> >>>
> >>> On Tue, Sep 13, 2016 at 7:31 PM Shawn Erickson 
> wrote:
> >>> I hit this issue as well. I had an early email on this list regarding
> do this topic, not in a situation to search for it. It is a short coming in
> how escaping can be applied to things like optional closures.
> >>>
> >>> I was in the process of authoring an email for swift evolution about
> it and haven't yet gotten around to filing a defect about it.
> >>>
> >>> -Shawn
> >>> On Tue, Sep 13, 2016 at 7:27 PM Rick Mann via swift-users <
> swift-users@swift.org> wrote:
> >>> I'm trying to write this function. The errorHandler: parameter is
> modeled after the NSFileManager enumerate() function. If I include the
> @escaping you see there, I get the error "@escaping may only be applied to
> parameters of function type".
> >>>
> >>> The second parameter, iterator:, seems to have no problems with
> @escaping.
> >>>
> >>> func
> >>> iterate(directory inURL: URL?,
> >>>includingPropertiesForKeys: [URLResourceKey]? = nil,
> >>>options: FileManager.DirectoryEnumerationOptions = [],
> >>>errorHandler inErrorHandler: (@escaping (URL, Error) -> Bool)?
> = nil,
> >>>iterator inIterator: (@escaping (URL) throws -> ())) rethrows
> >>> {
> >>> }
> >>>
> >>> I'm not sure why I can't apply @escaping here. Can anyone enlighten
> me? Thank you.
> >>>
> >>> --
> >>> 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
> >>
> >
> >
> > --
> > Rick Mann
> > rm...@latencyzero.com
> >
> >
>
>

Re: [swift-users] @escaping may only be applied to parameters of function type

[Michael Ilseman via swift-users]

> On Sep 13, 2016, at 8:14 PM, Rick Mann  wrote:
> 
> But the Apple declaration (accessible via Xcode) of the method it's based on 
> looks like this:
> 
> open func enumerator(at url: URL,
>includingPropertiesForKeys keys: [URLResourceKey]?,
>options mask: FileManager.DirectoryEnumerationOptions = [],
>errorHandler handler: (@escaping (URL, Error) -> Bool)? = nil)
>-> FileManager.DirectoryEnumerator?
> 
> handler is optional, but has @escaping. Is this an artifact of how Xcode 
> presents system header files?
> 

That’s certainly funky. Might be that or a bug in the AST printer.

> 
>> On Sep 13, 2016, at 20:11 , Michael Ilseman  wrote:
>> 
>> TL;DR: The optional is already escaping, due to the fact that “T?" is sugar 
>> for Optional, and the noescape-by-default rule only applies to types in 
>> immediate parameter position. Current Swift master has much better 
>> diagnostics for this case.
>> 
>> There is not currently a general solution involving escapability of closure 
>> types used a generic parameters or tuple members, though such a thing would 
>> be useful in Swift 4.
>> 
>>> On Sep 13, 2016, at 7:42 PM, Shawn Erickson via swift-users 
>>>  wrote:
>>> 
>>> The following is the earlier thread I was talking about. 
>>> 
>>> [swift-users] Swift 3 (Xcode 8 GM) issue with @escaping 
>>> 
>>> -Shawn
>>> 
>>> On Tue, Sep 13, 2016 at 7:31 PM Shawn Erickson  wrote:
>>> I hit this issue as well. I had an early email on this list regarding do 
>>> this topic, not in a situation to search for it. It is a short coming in 
>>> how escaping can be applied to things like optional closures.
>>> 
>>> I was in the process of authoring an email for swift evolution about it and 
>>> haven't yet gotten around to filing a defect about it.
>>> 
>>> -Shawn
>>> On Tue, Sep 13, 2016 at 7:27 PM Rick Mann via swift-users 
>>>  wrote:
>>> I'm trying to write this function. The errorHandler: parameter is modeled 
>>> after the NSFileManager enumerate() function. If I include the @escaping 
>>> you see there, I get the error "@escaping may only be applied to parameters 
>>> of function type".
>>> 
>>> The second parameter, iterator:, seems to have no problems with @escaping.
>>> 
>>> func
>>> iterate(directory inURL: URL?,
>>>includingPropertiesForKeys: [URLResourceKey]? = nil,
>>>options: FileManager.DirectoryEnumerationOptions = [],
>>>errorHandler inErrorHandler: (@escaping (URL, Error) -> Bool)? = nil,
>>>iterator inIterator: (@escaping (URL) throws -> ())) rethrows
>>> {
>>> }
>>> 
>>> I'm not sure why I can't apply @escaping here. Can anyone enlighten me? 
>>> Thank you.
>>> 
>>> --
>>> 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
>> 
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 

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

Re: [swift-users] @escaping may only be applied to parameters of function type

[Rick Mann via swift-users]

But the Apple declaration (accessible via Xcode) of the method it's based on 
looks like this:

open func enumerator(at url: URL,
includingPropertiesForKeys keys: [URLResourceKey]?,
options mask: FileManager.DirectoryEnumerationOptions = [],
errorHandler handler: (@escaping (URL, Error) -> Bool)? = nil)
-> FileManager.DirectoryEnumerator?

handler is optional, but has @escaping. Is this an artifact of how Xcode 
presents system header files?


> On Sep 13, 2016, at 20:11 , Michael Ilseman  wrote:
> 
> TL;DR: The optional is already escaping, due to the fact that “T?" is sugar 
> for Optional, and the noescape-by-default rule only applies to types in 
> immediate parameter position. Current Swift master has much better 
> diagnostics for this case.
> 
> There is not currently a general solution involving escapability of closure 
> types used a generic parameters or tuple members, though such a thing would 
> be useful in Swift 4.
> 
>> On Sep 13, 2016, at 7:42 PM, Shawn Erickson via swift-users 
>>  wrote:
>> 
>> The following is the earlier thread I was talking about. 
>> 
>> [swift-users] Swift 3 (Xcode 8 GM) issue with @escaping 
>> 
>> -Shawn
>> 
>> On Tue, Sep 13, 2016 at 7:31 PM Shawn Erickson  wrote:
>> I hit this issue as well. I had an early email on this list regarding do 
>> this topic, not in a situation to search for it. It is a short coming in how 
>> escaping can be applied to things like optional closures.
>> 
>> I was in the process of authoring an email for swift evolution about it and 
>> haven't yet gotten around to filing a defect about it.
>> 
>> -Shawn
>> On Tue, Sep 13, 2016 at 7:27 PM Rick Mann via swift-users 
>>  wrote:
>> I'm trying to write this function. The errorHandler: parameter is modeled 
>> after the NSFileManager enumerate() function. If I include the @escaping you 
>> see there, I get the error "@escaping may only be applied to parameters of 
>> function type".
>> 
>> The second parameter, iterator:, seems to have no problems with @escaping.
>> 
>> func
>> iterate(directory inURL: URL?,
>> includingPropertiesForKeys: [URLResourceKey]? = nil,
>> options: FileManager.DirectoryEnumerationOptions = [],
>> errorHandler inErrorHandler: (@escaping (URL, Error) -> Bool)? = nil,
>> iterator inIterator: (@escaping (URL) throws -> ())) rethrows
>> {
>> }
>> 
>> I'm not sure why I can't apply @escaping here. Can anyone enlighten me? 
>> Thank you.
>> 
>> --
>> 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
> 


-- 
Rick Mann
rm...@latencyzero.com


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

Re: [swift-users] @escaping may only be applied to parameters of function type

[Michael Ilseman via swift-users]

TL;DR: The optional is already escaping, due to the fact that “T?" is sugar for 
Optional, and the noescape-by-default rule only applies to types in 
immediate parameter position. Current Swift master has much better diagnostics 
for this case.

There is not currently a general solution involving escapability of closure 
types used a generic parameters or tuple members, though such a thing would be 
useful in Swift 4.

> On Sep 13, 2016, at 7:42 PM, Shawn Erickson via swift-users 
>  wrote:
> 
> The following is the earlier thread I was talking about. 
> 
> [swift-users] Swift 3 (Xcode 8 GM) issue with @escaping  
> 
> 
> -Shawn
> 
> On Tue, Sep 13, 2016 at 7:31 PM Shawn Erickson  > wrote:
> I hit this issue as well. I had an early email on this list regarding do this 
> topic, not in a situation to search for it. It is a short coming in how 
> escaping can be applied to things like optional closures.
> 
> I was in the process of authoring an email for swift evolution about it and 
> haven't yet gotten around to filing a defect about it.
> 
> -Shawn
> On Tue, Sep 13, 2016 at 7:27 PM Rick Mann via swift-users 
> > wrote:
> I'm trying to write this function. The errorHandler: parameter is modeled 
> after the NSFileManager enumerate() function. If I include the @escaping you 
> see there, I get the error "@escaping may only be applied to parameters of 
> function type".
> 
> The second parameter, iterator:, seems to have no problems with @escaping.
> 
> func
> iterate(directory inURL: URL?,
> includingPropertiesForKeys: [URLResourceKey]? = nil,
> options: FileManager.DirectoryEnumerationOptions = [],
> errorHandler inErrorHandler: (@escaping (URL, Error) -> Bool)? = nil,
> iterator inIterator: (@escaping (URL) throws -> ())) rethrows
> {
> }
> 
> I'm not sure why I can't apply @escaping here. Can anyone enlighten me? Thank 
> you.
> 
> --
> 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

Re: [swift-users] @escaping may only be applied to parameters of function type

[Shawn Erickson via swift-users]

The following is the earlier thread I was talking about.

[swift-users] Swift 3 (Xcode 8 GM) issue with @escaping


-Shawn

On Tue, Sep 13, 2016 at 7:31 PM Shawn Erickson  wrote:

> I hit this issue as well. I had an early email on this list regarding do
> this topic, not in a situation to search for it. It is a short coming in
> how escaping can be applied to things like optional closures.
>
> I was in the process of authoring an email for swift evolution about it
> and haven't yet gotten around to filing a defect about it.
>
> -Shawn
> On Tue, Sep 13, 2016 at 7:27 PM Rick Mann via swift-users <
> swift-users@swift.org> wrote:
>
>> I'm trying to write this function. The errorHandler: parameter is modeled
>> after the NSFileManager enumerate() function. If I include the @escaping
>> you see there, I get the error "@escaping may only be applied to parameters
>> of function type".
>>
>> The second parameter, iterator:, seems to have no problems with @escaping.
>>
>> func
>> iterate(directory inURL: URL?,
>> includingPropertiesForKeys: [URLResourceKey]? = nil,
>> options: FileManager.DirectoryEnumerationOptions = [],
>> errorHandler inErrorHandler: (@escaping (URL, Error) -> Bool)? =
>> nil,
>> iterator inIterator: (@escaping (URL) throws -> ())) rethrows
>> {
>> }
>>
>> I'm not sure why I can't apply @escaping here. Can anyone enlighten me?
>> Thank you.
>>
>> --
>> Rick Mann
>> rm...@latencyzero.com
>>
>>
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] @escaping may only be applied to parameters of function type

[Shawn Erickson via swift-users]

I hit this issue as well. I had an early email on this list regarding do
this topic, not in a situation to search for it. It is a short coming in
how escaping can be applied to things like optional closures.

I was in the process of authoring an email for swift evolution about it and
haven't yet gotten around to filing a defect about it.

-Shawn
On Tue, Sep 13, 2016 at 7:27 PM Rick Mann via swift-users <
swift-users@swift.org> wrote:

> I'm trying to write this function. The errorHandler: parameter is modeled
> after the NSFileManager enumerate() function. If I include the @escaping
> you see there, I get the error "@escaping may only be applied to parameters
> of function type".
>
> The second parameter, iterator:, seems to have no problems with @escaping.
>
> func
> iterate(directory inURL: URL?,
> includingPropertiesForKeys: [URLResourceKey]? = nil,
> options: FileManager.DirectoryEnumerationOptions = [],
> errorHandler inErrorHandler: (@escaping (URL, Error) -> Bool)? =
> nil,
> iterator inIterator: (@escaping (URL) throws -> ())) rethrows
> {
> }
>
> I'm not sure why I can't apply @escaping here. Can anyone enlighten me?
> Thank you.
>
> --
> Rick Mann
> rm...@latencyzero.com
>
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift and Xcode along with Playgrounds is full of bugs

[Shyamal Chandra via swift-users]

Hi Adam,

What are you talking about?  If swift.org bug reporting doesn't work, where
do you go?  You pay money for support but you don't get that from Apple.
That's unprofessional by Apple; not my complaint that they don't handle the
bug reports in a timely-fashion.

Thanks!

Best,

Shyamal Chandra
shyam...@gmail.com
Linkedin: http://www.linkedin.com/in/shyamalc
Phone: 620-719-9064

On Tue, Sep 13, 2016 at 9:28 PM, Adam Eberbach  wrote:

> If you need yet another perspective, your tone does seem abrasive. This is
> not the place for regretting how Apple handles bug reports.
>
> Best regards,
> Adam Eberbach
>
> On 14 Sep. 2016, at 12:24 pm, Shyamal Chandra via swift-users <
> swift-users@swift.org> wrote:
>
> Hi Shawn,
>
> Could you give me examples of what I said was clearly "unprofessional"?
> Two months for a bug because open source is "do it yourself".  This sounds
> like a crappy support team by a large multinational company that open
> sources non-functional Linux ports of its language.  I gave clear examples
> and bugs so I don't understand why you are getting defensive and hammering
> me with the "unprofessional" word.  First, address the issues and the bugs;
> I gave you clear examples and you circumvent those issues and flag the post
> because you don't want to confront that the tooling is buggy and flaky.
>
> I believe that a company of Apple's stature is unprofessional when they
> deliver buggy code to their customers that they pay money for.  Before you
> respond to this message, please address the bugs that I hyperlinked and the
> forum question problem.  You are wasting my time.
>
> Thanks!
>
> Best,
>
> Shyamal Chandra
> shyam...@gmail.com
> Linkedin: http://www.linkedin.com/in/shyamalc
> Phone: 620-719-9064
>
> On Tue, Sep 13, 2016 at 9:16 PM, Shawn Erickson  wrote:
>
>> You message are really coming across with an unprofessional tone. I
>> understand you are frustrated but folks inside and outside of Apple have
>> been working their butts off and frankly deserve a little more civility.
>>
>> Anyway, the Linux side of things is very much an open source - do it
>> yourself - type of thing at this time. I am sure folks would love to have
>> the issues and short coming addressed but need folks to step forward.
>>
>> If you would like to talk specifics about swift issues you are having a
>> fair number of folks are on this list and possibly could help.
>>
>> Also note Apple folks are likely a little burned out right now with all
>> of the crazy work closing out - as best they could - on Swift 3 and Xcode
>> 8, etc. so they may not be the quickest to respond.
>>
>> -Shawn
>> On Tue, Sep 13, 2016 at 6:53 PM Shyamal Chandra via swift-users <
>> swift-users@swift.org> wrote:
>>
>>> I am not arguing; I am bringing up defect in the Apple way of handling
>>> bugs for Swift, Xcode, and Playgrounds.  Am I supposed to wait for eternity?
>>>
>>> On Tuesday, September 13, 2016, Jens Alfke  wrote:
>>>

 On Sep 13, 2016, at 6:27 PM, Shyamal Chandra 
 wrote:

 Do you really think that is a viable option again?


 No, you’re right. Reporting bugs is clearly the least viable option,
 except for all the other options* (like arguing on mailing lists.)

 —Jens

 * With apologies to Winston Churchill

>>>
>>>
>>> --
>>> Sent from Gmail Mobile
>>> ___
>>> 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] Swift and Xcode along with Playgrounds is full of bugs

[Adam Eberbach via swift-users]

If you need yet another perspective, your tone does seem abrasive. This is not 
the place for regretting how Apple handles bug reports.

Best regards,
Adam Eberbach

> On 14 Sep. 2016, at 12:24 pm, Shyamal Chandra via swift-users 
>  wrote:
> 
> Hi Shawn,
> 
> Could you give me examples of what I said was clearly "unprofessional"?  Two 
> months for a bug because open source is "do it yourself".  This sounds like a 
> crappy support team by a large multinational company that open sources 
> non-functional Linux ports of its language.  I gave clear examples and bugs 
> so I don't understand why you are getting defensive and hammering me with the 
> "unprofessional" word.  First, address the issues and the bugs; I gave you 
> clear examples and you circumvent those issues and flag the post because you 
> don't want to confront that the tooling is buggy and flaky.
> 
> I believe that a company of Apple's stature is unprofessional when they 
> deliver buggy code to their customers that they pay money for.  Before you 
> respond to this message, please address the bugs that I hyperlinked and the 
> forum question problem.  You are wasting my time.
> 
> Thanks!
> 
> Best,
> 
> Shyamal Chandra
> shyam...@gmail.com
> Linkedin: http://www.linkedin.com/in/shyamalc
> Phone: 620-719-9064
> 
>> On Tue, Sep 13, 2016 at 9:16 PM, Shawn Erickson  wrote:
>> You message are really coming across with an unprofessional tone. I 
>> understand you are frustrated but folks inside and outside of Apple have 
>> been working their butts off and frankly deserve a little more civility.
>> 
>> Anyway, the Linux side of things is very much an open source - do it 
>> yourself - type of thing at this time. I am sure folks would love to have 
>> the issues and short coming addressed but need folks to step forward.
>> 
>> If you would like to talk specifics about swift issues you are having a fair 
>> number of folks are on this list and possibly could help.
>> 
>> Also note Apple folks are likely a little burned out right now with all of 
>> the crazy work closing out - as best they could - on Swift 3 and Xcode 8, 
>> etc. so they may not be the quickest to respond.
>> 
>> -Shawn
>>> On Tue, Sep 13, 2016 at 6:53 PM Shyamal Chandra via swift-users 
>>>  wrote:
>>> I am not arguing; I am bringing up defect in the Apple way of handling bugs 
>>> for Swift, Xcode, and Playgrounds.  Am I supposed to wait for eternity?
>>> 
 On Tuesday, September 13, 2016, Jens Alfke  wrote:
 
> On Sep 13, 2016, at 6:27 PM, Shyamal Chandra  wrote:
> 
> Do you really think that is a viable option again?
 
 No, you’re right. Reporting bugs is clearly the least viable option, 
 except for all the other options* (like arguing on mailing lists.)
 
 —Jens
 
 * With apologies to Winston Churchill
>>> 
>>> 
>>> -- 
>>> Sent from Gmail Mobile
>>> ___
>>> 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] @escaping may only be applied to parameters of function type

[Rick Mann via swift-users]

I'm trying to write this function. The errorHandler: parameter is modeled after 
the NSFileManager enumerate() function. If I include the @escaping you see 
there, I get the error "@escaping may only be applied to parameters of function 
type".

The second parameter, iterator:, seems to have no problems with @escaping.

func
iterate(directory inURL: URL?,
includingPropertiesForKeys: [URLResourceKey]? = nil,
options: FileManager.DirectoryEnumerationOptions = [],
errorHandler inErrorHandler: (@escaping (URL, Error) -> Bool)? = nil,
iterator inIterator: (@escaping (URL) throws -> ())) rethrows
{
}

I'm not sure why I can't apply @escaping here. Can anyone enlighten me? Thank 
you.

-- 
Rick Mann
rm...@latencyzero.com


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

Re: [swift-users] Swift and Xcode along with Playgrounds is full of bugs

[Shawn Erickson via swift-users]

You message are really coming across with an unprofessional tone. I
understand you are frustrated but folks inside and outside of Apple have
been working their butts off and frankly deserve a little more civility.

Anyway, the Linux side of things is very much an open source - do it
yourself - type of thing at this time. I am sure folks would love to have
the issues and short coming addressed but need folks to step forward.

If you would like to talk specifics about swift issues you are having a
fair number of folks are on this list and possibly could help.

Also note Apple folks are likely a little burned out right now with all of
the crazy work closing out - as best they could - on Swift 3 and Xcode 8,
etc. so they may not be the quickest to respond.

-Shawn
On Tue, Sep 13, 2016 at 6:53 PM Shyamal Chandra via swift-users <
swift-users@swift.org> wrote:

> I am not arguing; I am bringing up defect in the Apple way of handling
> bugs for Swift, Xcode, and Playgrounds.  Am I supposed to wait for eternity?
>
> On Tuesday, September 13, 2016, Jens Alfke  wrote:
>
>>
>> On Sep 13, 2016, at 6:27 PM, Shyamal Chandra  wrote:
>>
>> Do you really think that is a viable option again?
>>
>>
>> No, you’re right. Reporting bugs is clearly the least viable option,
>> except for all the other options* (like arguing on mailing lists.)
>>
>> —Jens
>>
>> * With apologies to Winston Churchill
>>
>
>
> --
> Sent from Gmail Mobile
> ___
> 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 and Xcode along with Playgrounds is full of bugs

[Shyamal Chandra via swift-users]

I am not arguing; I am bringing up defect in the Apple way of handling bugs
for Swift, Xcode, and Playgrounds.  Am I supposed to wait for eternity?

On Tuesday, September 13, 2016, Jens Alfke  wrote:

>
> On Sep 13, 2016, at 6:27 PM, Shyamal Chandra  > wrote:
>
> Do you really think that is a viable option again?
>
>
> No, you’re right. Reporting bugs is clearly the least viable option,
> except for all the other options* (like arguing on mailing lists.)
>
> —Jens
>
> * With apologies to Winston Churchill
>


-- 
Sent from Gmail Mobile
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift and Xcode along with Playgrounds is full of bugs

[Jens Alfke via swift-users]

> On Sep 13, 2016, at 6:27 PM, Shyamal Chandra  wrote:
> 
> Do you really think that is a viable option again?

No, you’re right. Reporting bugs is clearly the least viable option, except for 
all the other options* (like arguing on mailing lists.)

—Jens

* With apologies to Winston Churchill___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Swift and Xcode along with Playgrounds is full of bugs

[Shyamal Chandra via swift-users]

I posted an error with ubuntu running on swift.org and it is currently
medium priority and still hasn't been fixed by an "open source" team member
and it has been more than two months.

Here is the error:
https://bugs.swift.org/browse/SR-1998

Do you really think that is a viable option again?

On Tuesday, September 13, 2016, Jens Alfke > wrote:

>
> On Sep 13, 2016, at 5:34 PM, Shyamal Chandra via swift-users <
> swift-users@swift.org> wrote:
>
> Here is a forum question that I posted a while back.  The latest post says
> to file a bug under the bug report.  I have had mixed success with the bug
> reporter tool from Apple; most of the time, they ask for the system
> diagnostics and then, tell you to update your version.  Sometimes, they
> just close the issue and nothing happens.
>
>
> Apple’s bug-reporting process is not the greatest, I agree. Most of that
> is a side effect of how secretive and opaque Apple is: you can’t see bugs
> anyone else has filed, and once you file a bug you can’t see what’s going
> on internally, and if it gets marked as a dup you can’t see the progress of
> the bug it was duped against.
>
> Fortunately Swift is now open source and has its own more open bug tracker
> at bugs.swift.org.
>
> I was doing something "simple" in Playgrounds and my version of
> Playgrounds doesn't function properly because it is emitting an error when
> I write bug-free code.  Why is Playgrounds so flaky?
>
>
> Now you’re talking about Xcode, not about Swift itself. Everyone has a
> love/hate relationship with Xcode (even inside Apple; I used to work
> there.) It’s a hugely complex app with a thousand competing demands it has
> to fulfill. Some parts of it suck. Generally they get better over time. The
> Swift support —  and playgrounds in particular — still seem pretty rough. I
> still spend most of my time with Obj-C and C++, and whenever I do Swift
> development it feels like I’m using a different, much less stable IDE! I
> imagine it still needs more time to mature.
>
> I don’t know if this mailing list is the best place to discuss Xcode
> issues, even ones related to Swift. Apple has an xcode-users mailing list
> at http://lists.apple.com . It’s a good quality list that I’ve been on
> for years.
>
> —Jens
>


-- 
Sent from Gmail Mobile
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift and Xcode along with Playgrounds is full of bugs

[Jens Alfke via swift-users]

> On Sep 13, 2016, at 5:34 PM, Shyamal Chandra via swift-users 
>  wrote:
> 
> Here is a forum question that I posted a while back.  The latest post says to 
> file a bug under the bug report.  I have had mixed success with the bug 
> reporter tool from Apple; most of the time, they ask for the system 
> diagnostics and then, tell you to update your version.  Sometimes, they just 
> close the issue and nothing happens.

Apple’s bug-reporting process is not the greatest, I agree. Most of that is a 
side effect of how secretive and opaque Apple is: you can’t see bugs anyone 
else has filed, and once you file a bug you can’t see what’s going on 
internally, and if it gets marked as a dup you can’t see the progress of the 
bug it was duped against.

Fortunately Swift is now open source and has its own more open bug tracker at 
bugs.swift.org.

> I was doing something "simple" in Playgrounds and my version of Playgrounds 
> doesn't function properly because it is emitting an error when I write 
> bug-free code.  Why is Playgrounds so flaky?

Now you’re talking about Xcode, not about Swift itself. Everyone has a 
love/hate relationship with Xcode (even inside Apple; I used to work there.) 
It’s a hugely complex app with a thousand competing demands it has to fulfill. 
Some parts of it suck. Generally they get better over time. The Swift support — 
 and playgrounds in particular — still seem pretty rough. I still spend most of 
my time with Obj-C and C++, and whenever I do Swift development it feels like 
I’m using a different, much less stable IDE! I imagine it still needs more time 
to mature.

I don’t know if this mailing list is the best place to discuss Xcode issues, 
even ones related to Swift. Apple has an xcode-users mailing list at 
http://lists.apple.com . It’s a good quality list that I’ve been on for years.

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

Re: [swift-users] Method of same name is shadowing a property in Swift 3

[Jens Alfke via swift-users]

> On Sep 13, 2016, at 4:47 PM, Zhao Xin  wrote:
> 
> You said your issue only existed in Swift 3. However, you issue still exists 
> in Xcode 7.3.1, which uses Swift 2.2. I tested your playground code.

Interesting. I think the difference is that prior to Swift 3, the original 
Objective-C method was translated into Swift differently — I believe it came 
out as keyAtIndex() — so it didn’t trigger this name collision issue.

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

Re: [swift-users] Swift and Xcode along with Playgrounds is full of bugs

[Shyamal Chandra via swift-users]

Hi Chris,

Here is a forum question that I posted a while back.  The latest post says
to file a bug under the bug report.  I have had mixed success with the bug
reporter tool from Apple; most of the time, they ask for the system
diagnostics and then, tell you to update your version.  Sometimes, they
just close the issue and nothing happens.

Here's the post:

https://forums.developer.apple.com/thread/61953 (Playgrounds error)

I was doing something "simple" in Playgrounds and my version of Playgrounds
doesn't function properly because it is emitting an error when I write
bug-free code.  Why is Playgrounds so flaky?  Sometimes, it shows the
output on the right side; sometime, it doesn't.


Thanks!

Best,

Shyamal Chandra
shyam...@gmail.com
Linkedin: http://www.linkedin.com/in/shyamalc
Phone: 620-719-9064

On Tue, Sep 13, 2016 at 7:02 PM, Chris Lattner  wrote:

> On Sep 12, 2016, at 3:03 PM, Shyamal Chandra via swift-users <
> swift-users@swift.org> wrote:
> > Hope you are doing well!
> >
> > Swift is very volatile language that keeps on changing with every new
> version of Xcode.  When you are trying to run old code with different
> syntax, you run into problems because the code is no longer compatible.
> Instead of moving onto Swift 3, 4, and 5 (with different syntax), why don't
> you standardize the library and language operations and functions for the
> different package and frameworks included with Xcode
>
> The subject line of this message seems like it is intended to be
> provocative, not helpful.
>
> Despite that, you’ll be happy to know that the goal of Swift 4 is to be
> source compatible with Swift 3, so the concerns that you are complaining
> about are historic, not future problems.
>
> > because I have already submitted multiple bugs to the bug report that
> are with the official release of Xcode and I am very disappointed with the
> software quality.
>
> I don’t see any radars filed by you in the system, but perhaps they are
> just under a different name.  In any case, thank you for filing bugs, we do
> read and care about them!  Please send me the radar numbers (off list if
> you prefer) and I’ll take a look.
>
> -Chris
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Swift 3.0 released!

[Ted kremenek via swift-users]

Hi everyone,

Swift 3.0 has been officially released:

https://swift.org/blog/swift-3-0-released/

This moment marks an incredible achievement for the Swift open source 
community.  The release is the culmination of an incredible amount of 
discussion and implementation work to bring it all together.

Beyond the changes to Swift itself, the Linux port has made great strides in 
Swift 3 with the first official release of the core libraries.  The Swift 
Package Manager is now officially available for building cross-platform Swift 
packages.

Thank you to everyone — and I mean everyone — who contributed to Swift 3 in 
some way.

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

Re: [swift-users] Swift and Xcode along with Playgrounds is full of bugs

[Chris Lattner via swift-users]

On Sep 12, 2016, at 3:03 PM, Shyamal Chandra via swift-users 
 wrote:
> Hope you are doing well!
> 
> Swift is very volatile language that keeps on changing with every new version 
> of Xcode.  When you are trying to run old code with different syntax, you run 
> into problems because the code is no longer compatible.  Instead of moving 
> onto Swift 3, 4, and 5 (with different syntax), why don't you standardize the 
> library and language operations and functions for the different package and 
> frameworks included with Xcode

The subject line of this message seems like it is intended to be provocative, 
not helpful.  

Despite that, you’ll be happy to know that the goal of Swift 4 is to be source 
compatible with Swift 3, so the concerns that you are complaining about are 
historic, not future problems.

> because I have already submitted multiple bugs to the bug report that are 
> with the official release of Xcode and I am very disappointed with the 
> software quality. 

I don’t see any radars filed by you in the system, but perhaps they are just 
under a different name.  In any case, thank you for filing bugs, we do read and 
care about them!  Please send me the radar numbers (off list if you prefer) and 
I’ll take a look. 

-Chris

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

Re: [swift-users] Method of same name is shadowing a property in Swift 3

[Jens Alfke via swift-users]

> On Sep 13, 2016, at 3:13 PM, Hooman Mehr  wrote:
> 
> I guess the reason this is happening is some attempt at backward 
> compatibility, but this is clearly causing a serious bug. Have you reported 
> it?

No; I’m not a Swift expert, and am not following the 3.0 transition closely 
enough to tell whether this is a bug or just some unfortunate but intentional 
fallout from the transition.

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

Re: [swift-users] Method of same name is shadowing a property in Swift 3

[Hooman Mehr via swift-users]

As I see it, this is serious bug. In Swift 3.0, parameter labels (or lack of 
them) are supposed to be a part of the function name. 
Otherwise, the two `key` definitions would create a name collision and should 
have been rejected in the first place. This should not happen, because only 
`key(at:)` should be treated as a method pointer and not `key`. Even the 
following example:

protocol QueryRow {
var key: Any { get }
func key(_ index: UInt) -> Any?
}

should not create a collision as method pointer now is `key(_:)` and not `key`. 
I guess the reason this is happening is some attempt at backward compatibility, 
but this is clearly causing a serious bug. Have you reported it?

> On Sep 13, 2016, at 1:13 PM, Jens Alfke via swift-users 
>  wrote:
> 
> One of my co-workers just noticed a problem with the (bridged) API of our 
> Objective-C framework, when used from Swift 3 (but not earlier). We have a 
> class CBLQueryRow that includes the following:
> 
>   @property (readonly) id key;
>   - (nullable id) keyAtIndex: (NSUInteger)index;
> 
> In Swift this becomes
>   open var key: Any { get }
>   open func key(at index: UInt) -> Any?
> 
> The problem is that any reference to `key` now seems to refer to a pointer to 
> the method, not to the property, leading to compiler diagnostics like the 
> following (where `row` is a CBLQueryRow):
> 
> TaskListsViewController.swift:95:40: warning: cast from '(UInt) -> Any?' to 
> unrelated type 'String' always fails
> cell.textLabel?.text = row.key as? String
>~~~ ^   ~~
> That’s a warning not an error, but obviously at runtime the `as?` would 
> always fail and result in nil.
> 
> This is rather bad for us, since the `key` property is a crucial part of the 
> API, while the `key()` method that pre-empts it is obscure and little-used.
> 
> I can reproduce this in a playground in Xcode 8 like so:
> 
> protocol QueryRow {
> var key: Any { get }
> func key(at index: UInt) -> Any?
> }
> 
> var row: QueryRow
> 
> row.key as? String
> In addition to the valid error about `row` being uninitialized, I also get 
> the cast failure.
> 
> What’s the best workaround for this?
> 
> —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

[swift-users] Method of same name is shadowing a property in Swift 3

[Jens Alfke via swift-users]

One of my co-workers just noticed a problem with the (bridged) API of our 
Objective-C framework, when used from Swift 3 (but not earlier). We have a 
class CBLQueryRow that includes the following:

@property (readonly) id key;
- (nullable id) keyAtIndex: (NSUInteger)index;

In Swift this becomes
open var key: Any { get }
open func key(at index: UInt) -> Any?

The problem is that any reference to `key` now seems to refer to a pointer to 
the method, not to the property, leading to compiler diagnostics like the 
following (where `row` is a CBLQueryRow):

TaskListsViewController.swift:95:40: warning: cast from '(UInt) -> Any?' to 
unrelated type 'String' always fails
cell.textLabel?.text = row.key as? String
   ~~~ ^   ~~
That’s a warning not an error, but obviously at runtime the `as?` would always 
fail and result in nil.

This is rather bad for us, since the `key` property is a crucial part of the 
API, while the `key()` method that pre-empts it is obscure and little-used.

I can reproduce this in a playground in Xcode 8 like so:

protocol QueryRow {
var key: Any { get }
func key(at index: UInt) -> Any?
}

var row: QueryRow

row.key as? String
In addition to the valid error about `row` being uninitialized, I also get the 
cast failure.

What’s the best workaround for this?

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

[swift-users] Canonical way to getifaddrs with SPM and Xcode

[Bouke Haarsma via swift-users]

Hi all,

I would like to know the canonical way to call C’s getifaddrs, defined in 
ifaddr.h, using Swift 3. It should compile from both Xcode and SPM (Darwin and 
Glibc). As this header is not imported by the Darwin (/Glibc as well?) library, 
so the header would need to be imported by my own code. I tried two different 
approaches, but both failed;

1. Define a system module package;

> module Cifaddrs [system] [extern_c] {
>   header "/usr/include/ifaddrs.h"
>   export *
> }

With both Xcode/SPM it fails with:

> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/module.modulemap:7:8:
>  error: redefinition of module 'Compression'
> module Compression [system] [extern_c] {
>^

2. Define a Clang module;

> Sources/Cifaddrs/include/Cifaddrs.h:
> #import 
> 
> Sources/Cifaddrs/Cifaddrs.c:
> (empty)

In Xcode it fails with:

> […]Sources/Cifaddrs/include/Cifaddrs.h:1:9: Include of non-modular header 
> inside framework module 'Cifaddrs'


Note that setting CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES doesn’t 
affect Swift compiler.

Building using ``swift build`` however works.

Both approaches feel like convoluted ways for something that would’ve been very 
easy with plain C. Many thanks in advantage for showing me an easier way :).

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

Re: [swift-users] Swift and Threads

[Gerriet M. Denkmann via swift-users]

> On 13 Sep 2016, at 14:49, Quinn The Eskimo! via swift-users 
>  wrote:
> 
> 
> On 13 Sep 2016, at 05:03, Gerriet M. Denkmann via swift-users 
>  wrote:
> 
>> Or is the code fundamentally wrong …?
> 
> This one.
> 
> You’re accessing a mutable value (`bitfield`) from multiple threads.  Swift 
> does not support that, even in situations like this where you’re sure that 
> the items are preallocated and that the threads are accessing non-overlapping 
> values.
> 
> As to how you fix this, it kinda depends on your final use for the array.  If 
> you’re OK with the results being split into per-thread chunks, you can have 
> each thread work on its own chunk and then pass the results back to the 
> ‘main’ thread when it’s done.  OTOH, if you need your results in one big 
> array, things get tricky.

Stephen J. Butler just suggested a solution (on CocoaDev) which works and is 
fast and uses no additional memory.

Here it is:

let nbrOfThreads = 8
let step = 2
let itemsPerThread = number * step
let bitLimit = nbrOfThreads * itemsPerThread
var bitfield = [Bool](count: bitLimit, repeatedValue: false)

let queue = dispatch_get_global_queue( DISPATCH_QUEUE_PRIORITY_HIGH, 0 );

bitfield.withUnsafeMutableBufferPointer { (inout bitfieldBuffer : 
UnsafeMutableBufferPointer) -> () in
dispatch_apply( Int(nbrOfThreads), queue ) { ( idx: size_t) -> Void in
let startIndex = itemsPerThread * Int(idx)
let endIndex = min( startIndex + itemsPerThread, bitLimit )
if talk { print("Thread[\(idx)] does \(startIndex) ..< \(endIndex)") }

var currIndex = startIndex
while( currIndex < endIndex )
{
bitfieldBuffer[currIndex] = true
currIndex += step
}
}
}

I hope that this is really thread-safe (testing it, I have no problems so far).

Kind regards,

Gerriet.

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

Re: [swift-users] Swift and Threads

[Quinn "The Eskimo!" via swift-users]

On 13 Sep 2016, at 05:03, Gerriet M. Denkmann via swift-users 
 wrote:

> Or is the code fundamentally wrong …?

This one.

You’re accessing a mutable value (`bitfield`) from multiple threads.  Swift 
does not support that, even in situations like this where you’re sure that the 
items are preallocated and that the threads are accessing non-overlapping 
values.

As to how you fix this, it kinda depends on your final use for the array.  If 
you’re OK with the results being split into per-thread chunks, you can have 
each thread work on its own chunk and then pass the results back to the ‘main’ 
thread when it’s done.  OTOH, if you need your results in one big array, things 
get tricky.

Share and Enjoy
--
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware


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