Re: [swift-users] Localization in Swift.

[Zhao Xin via swift-users]

Hello everyone. Thanks to you all for replies in this thread.

I am currently working on a Xcode Extension for this purpose. I would like
to bring it to github in this week. This will be my first Xcode extension,
also my first github open sourced project.


Zhaoxin

On Thu, Nov 3, 2016 at 6:14 AM, Dave Abrahams via swift-users <
swift-users@swift.org> wrote:

>
> on Wed Nov 02 2016, Jens Alfke  wrote:
>
> >> On Nov 2, 2016, at 12:50 PM, Dave Abrahams via swift-users <
> swift-users@swift.org> wrote:
> >>
> >> In my opinion, we can and must do much better for Swift.  If there's
> >> something about “%” formatting that you particularly value, I'd like to
> >> know about it, so I can make sure it's accomodated.
> >
> > It offers more control over formatting, like min/max widths, number
> > base, decimal places, etc. Yes, you can do this in the code inside the
> > interpolated string, but IMHO it’s awkward because it requires knowing
> > a bunch of extra methods for string conversion, truncation, etc. It’s
> > a lot easier for me to remember and type “%x” than it is to remember
> > and type the method that converts an int to a hex string.
>
> In my view this should look like
>
>   "... \(x.format(radix: 16, width: 12))... "
>
> Where the possible arguments to format() are statically known to the
> compiler (and code completion!) based on the type of x.
>
> >
> > Also (and more importantly for localization) the formatting details
> > are part of the localizable format string, not hardwired. One example
> > of this is formatting currency, where a US localization would use
> > “$%.2f” but other currencies might call for more or fewer decimal
> > places.
>
> Yep, I'm paying attention to that, thanks.
>
> > There are other examples where one might swap format strings for other
> > purposes like different-width layouts for monospaced/terminal output.
>
> I think we can leverage the same mechanisms used for localization to
> handle those.
>
> > There’s also a nonstandard extension used by Cocoa/CF’s formatters,
> > that allows the parameters to be reordered. (I haven’t used it so I
> > don’t know the syntax offhand.) This is of course important for
> > localization, to follow a language’s grammar.
>
> Right, that's crucial.
>
> > I think these features could be added to interpolation. Just as a
> > quick idea, maybe a syntax that allows formatting metacharacters to be
> > added at the start of the interpolation, like “Please pay $\((.2)
> > total)” where the “(.2) specifies two decimal places, or “The address
> > is \((x) addr)”.
>
> I think the “.format(...)” approach is better, but it's equally
> important that there are sufficient outside-the-Swift-source knobs for
> localizers to add language-specific formatting parameters.
>
> --
> -Dave
> ___
> 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] What is "binding" memory?

[Jordan Rose via swift-users]

> On Nov 2, 2016, at 15:50, Dave Abrahams via swift-users 
>  wrote:
> 
> 
> on Wed Nov 02 2016, Andrew Trick  > wrote:
> 
>>> On Nov 2, 2016, at 12:58 PM, Dave Abrahams via swift-users 
>>>  wrote:
>>> 
 At the top of the migration guide is a link to the memory model 
 explanation:
 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#memory-model-explanation
 
>> 
 "A memory location's bound type is an abstract, dynamic property of the 
 memory used to formalize
 type safety.”
 
 I’m not sure I like the “prepares the memory” language myself. Binding
 memory communicates to the compiler that the memory locations are safe
 for typed access. Nothing happens at runtime--until someone writes a
 type safety sanitizer. 
>>> 
>>> Well, that's a slight overstatement IMO.  Sanitizers aside, the main
>>> reason for these binding operations is that if you leave them out,
>>> something different *will* happen at runtime... something that will make
>>> your code do the wrong thing.
>>> 
>>> What I would say is that binding the memory has no immediate runtime
>>> cost... but it's absolutely required if you want your program to behave
>>> (and sometimes behaving correctly is a little slower than misbehaving).
>> 
>> Good clarification. I really did not mean to imply that binding memory
>> to a type has no effect on runtime behavior. Taken out of context,
>> “nothing happens at runtime” is quite an understatement.
>> 
>> The original poster seemed to have the impression that the operation
>> of binding memory itself might affect program state, 
> 
> Formally speaking, it does!
> 
>> independent of any compiler optimization. I want to make it clear that
>> a call to bindMemory(to:capacity:) has no observable runtime side
>> effects at the point of the call. 
> 
> Only because you can't observe what memory is bound to.
> 
>> But I need to throw in an exemption for future sanitizers.
> 
> I don't think you do; sanitizer actions are allowed under undefined
> behavior.

I think the difference here is that sanitizers affect program characteristics 
even for correct programs. Introducing a sanitizer can reduce optimization 
opportunities, changing an algorithm’s complexity. And of course, there’s 
always a bit of bookkeeping code being executed that wouldn’t be there 
otherwise.

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

Re: [swift-users] What is "binding" memory?

[Andrew Trick via swift-users]

> On Nov 2, 2016, at 3:50 PM, Dave Abrahams  wrote:
> 
>> The original poster seemed to have the impression that the operation
>> of binding memory itself might affect program state, 
> 
> Formally speaking, it does!

Oh boy. I keep failing at this. How does one formally distinguish between 
semantic state and actual state?
-Andy
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] What is "binding" memory?

[Dave Abrahams via swift-users]

on Wed Nov 02 2016, Andrew Trick  wrote:

>> On Nov 2, 2016, at 12:58 PM, Dave Abrahams via swift-users 
>>  wrote:
>> 
>>> At the top of the migration guide is a link to the memory model explanation:
>>>
> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#memory-model-explanation
>>> 
>
>>> "A memory location's bound type is an abstract, dynamic property of the 
>>> memory used to formalize
>>> type safety.”
>>> 
>>> I’m not sure I like the “prepares the memory” language myself. Binding
>>> memory communicates to the compiler that the memory locations are safe
>>> for typed access. Nothing happens at runtime--until someone writes a
>>> type safety sanitizer. 
>> 
>> Well, that's a slight overstatement IMO.  Sanitizers aside, the main
>> reason for these binding operations is that if you leave them out,
>> something different *will* happen at runtime... something that will make
>> your code do the wrong thing.
>> 
>> What I would say is that binding the memory has no immediate runtime
>> cost... but it's absolutely required if you want your program to behave
>> (and sometimes behaving correctly is a little slower than misbehaving).
>
> Good clarification. I really did not mean to imply that binding memory
> to a type has no effect on runtime behavior. Taken out of context,
> “nothing happens at runtime” is quite an understatement.
>
> The original poster seemed to have the impression that the operation
> of binding memory itself might affect program state, 

Formally speaking, it does!

> independent of any compiler optimization. I want to make it clear that
> a call to bindMemory(to:capacity:) has no observable runtime side
> effects at the point of the call. 

Only because you can't observe what memory is bound to.

> But I need to throw in an exemption for future sanitizers.

I don't think you do; sanitizer actions are allowed under undefined
behavior.

-- 
-Dave
___
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 Nov 1, 2016, at 9:50 PM, Shyamal Chandra  wrote:
> Hi Chris,
> 
> First of all, there is tremendous instability with Xcode Playgrounds. 

Hi Shyamal,

The vast majority of the instability of playgrounds is a result of the compiler 
code which is already open source.  I look forward to you sending in patches to 
improve Swift: if you’re looking for a good starting place, there are a large 
number of submitted bugs in JIRA which we’d love your help on, and a large 
number of known crashers tracked in the validation suite.

-Chris


> I paste the same simple code into Xcode Playgrounds; sometimes, it works and 
> sometimes, it doesn't work.  Why don't you make the Playgrounds open source 
> so I can investigate?  You should tell this to Tim Cook as soon as possible.  
> I wanted to add Swift to the list of languages in Juypter for workbook usage. 
>  If a project is closed-source, I cannot do anything without looking at 
> documented code.  The documentation for Xcode Playgrounds is not there.  For 
> the XCPlayground library, there is just an API call reference that is 
> sparsely documented.   I can wait for infinity for a response on the forums 
> but Apple should provide better support rather than charging money for each 
> technical support call.  This is disappointing since Apple was founded to 
> make computing easy, not hard on purpose, making code writing a black art.
> 
> Thanks!
> 
> Best,
> 
> Shyamal Chandra
> shyam...@gmail.com 
> Linkedin: http://www.linkedin.com/in/shyamalc 
> 
> Phone: 620-719-9064
> 
> On Tue, Sep 13, 2016 at 10:56 PM, Chris Lattner  > wrote:
> 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 
>> > 

Re: [swift-users] Localization in Swift.

[Dave Abrahams via swift-users]

on Wed Nov 02 2016, Jens Alfke  wrote:

>> On Nov 2, 2016, at 12:50 PM, Dave Abrahams via swift-users 
>>  wrote:
>> 
>> In my opinion, we can and must do much better for Swift.  If there's
>> something about “%” formatting that you particularly value, I'd like to
>> know about it, so I can make sure it's accomodated.
>
> It offers more control over formatting, like min/max widths, number
> base, decimal places, etc. Yes, you can do this in the code inside the
> interpolated string, but IMHO it’s awkward because it requires knowing
> a bunch of extra methods for string conversion, truncation, etc. It’s
> a lot easier for me to remember and type “%x” than it is to remember
> and type the method that converts an int to a hex string.

In my view this should look like 

  "... \(x.format(radix: 16, width: 12))... "

Where the possible arguments to format() are statically known to the
compiler (and code completion!) based on the type of x.

>
> Also (and more importantly for localization) the formatting details
> are part of the localizable format string, not hardwired. One example
> of this is formatting currency, where a US localization would use
> “$%.2f” but other currencies might call for more or fewer decimal
> places. 

Yep, I'm paying attention to that, thanks.

> There are other examples where one might swap format strings for other
> purposes like different-width layouts for monospaced/terminal output.

I think we can leverage the same mechanisms used for localization to
handle those.

> There’s also a nonstandard extension used by Cocoa/CF’s formatters,
> that allows the parameters to be reordered. (I haven’t used it so I
> don’t know the syntax offhand.) This is of course important for
> localization, to follow a language’s grammar.

Right, that's crucial.

> I think these features could be added to interpolation. Just as a
> quick idea, maybe a syntax that allows formatting metacharacters to be
> added at the start of the interpolation, like “Please pay $\((.2)
> total)” where the “(.2) specifies two decimal places, or “The address
> is \((x) addr)”.

I think the “.format(...)” approach is better, but it's equally
important that there are sufficient outside-the-Swift-source knobs for
localizers to add language-specific formatting parameters.

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

Re: [swift-users] Autoreleasepool for Ubuntu

[Greg Parker via swift-users]

> On Nov 2, 2016, at 1:08 PM, Joe Groff via swift-users  
> wrote:
> 
>> On Nov 2, 2016, at 1:00 PM, Philippe Hausler > > wrote:
>> 
>> See:
>> 
>> https://github.com/apple/swift-corelibs-foundation/blob/d015466450b2675037c6f1ace8e17e73050ccfb9/Foundation/NSURL.swift#L561
>>  
>> 
>> 
>> This is far and few between of cases that it would be useful but there are a 
>> few APIs that we have not been able to express without being able to 
>> autorelease items. Most of which we have either forbidden in Linux or 
>> redesigned because they were sub-par swift experiences. However it seems 
>> reasonable to have a minimal shim to provide cross platform code 
>> compatibility even if it does next to nothing. That way trivial code as the 
>> original issue showed can easily be directly compiled on either platform 
>> without littering gnarly #ifdefs about.
> 
> In the fullness of time, the borrow model will hopefully give us a way to 
> represent those kinds of "returns inner pointer" APIs safely in Swift without 
> relying on dynamic lifetime extension, or awkward 'with { ... }' callbacks.

Not to mention using autoreleasepool to handle returns-inner-pointer isn't 
memory safe anyway. If the autorelease pool pops too soon then you end up with 
a dangling pointer that no amount of compiler analysis can detect. 


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


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

Re: [swift-users] Element vs. Iterator.Element

[Slava Pestov via swift-users]

I don’t remember the details, but IIRC ‘Iterator’ is an inferred associated 
type on Array, so it cannot appear in the ‘where’ clause of an extension. This 
is a known limitation of the name lookup code — presently it cannot recur into 
associated type inference due to circularity. We plan on addressing this with 
the ‘iterative declaration checker’, but that is some ways off.

Slava

> On Oct 31, 2016, at 5:28 AM, Toni Suter via swift-users 
>  wrote:
> 
> Hi,
> 
> This extension on Array works as expected:
> 
> extension Array where Element: CustomStringConvertible {
> func f(_ x: Element) -> String {
> return x.description
> }
> }
> 
> But when I use Iterator.Element instead, I get an error message (error: value 
> of type 'Element' has no member 'description'):
> 
> extension Array where Iterator.Element: CustomStringConvertible {
> func f(_ x: Iterator.Element) -> String {
> return x.description
> }
> }
> 
> I assume this is a type checker bug, but before I report it, I wanted to make 
> sure that that’s really the case. Or is there a difference between Element and
> Iterator.Element?
> 
> Thanks and best regards,
> Toni
> ___
> 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] wishing I could cast (sort of) to protocol with associated type

[Jordan Rose via swift-users]

The only real way to do this today is to have two layers of protocol:

protocol SpecialControllerBase {
  var currentValueBase: SpecialValue? { get }
}
protocol SpecialController: SpecialControllerBase {
  associatedtype SpecialValueType : SpecialValue
  var currentValue: SpecialValueType? { get }
}
extension SpecialController {
  var currentValueBase: SpecialValue? { return self.currentValue }
}

Supporting this natively is the feature called generalized existentials, 
described in the “Generics Manifesto 
”
 of potential future Swift features. This has a lot of design and 
implementation considerations, so it’s not planned to happen right away, but 
it’s definitely a heavily-requested feature.

Jordan


> On Nov 2, 2016, at 12:31, Robert Nikander via swift-users 
>  wrote:
> 
> Hi,
> 
> In the following code, I want to test if x is a `SpecialController`. If it 
> is, I want to get the `currentValue` as a `SpecialValue`. How do you do this? 
> If not with a cast, then some other technique.
> 
> I understand the error, and that SpecialController by itself is not a simple 
> type to cast to. But it seems like what I’m saying is logically consistent 
> and not that complicated. Is there really no way to *say* it in Swift?
> 
>protocol SpecialController {
>associated type SpecialValueType : SpecialValue
>var currentValue: SpecialValueType? { get }
>}
>...
>var x: AnyObject = ...
>if let sc = x as? SpecialController {  // does not compile
> 
> Rob
> ___
> 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] Autoreleasepool for Ubuntu

[Bernardo Breder via swift-users]

2016-11-02 18:36 GMT-02:00 Joe Groff :

>
> On Nov 2, 2016, at 1:16 PM, Bernardo Breder via swift-users <
> swift-users@swift.org> wrote:
>
> In my http server i want to manager the memory all the time that we close
> a socket, like the example of manager in this link:
> http://stackoverflow.com/questions/25860942/is-it-nece
> ssary-to-use-autoreleasepool-in-a-swift-program
>
> Algorithm that show the ideia:
>
> *func request(content) { ... }*
>
> *let server = myserver()*
> *while let client = server.accept() {*
> *  autoreleasepool {*
> *client.send(request(client.read()))*
> *client.close()*
> *  }*
> *}*
>
>
>
The algorithm that i send is a example of server code and this code will
execute in a ubuntu environment. When i install in the ubuntu, the swiftc
show me that the *autoreleasepool *is "use of unresolved identifier
'autoreleasepool'". I want to clean the memory all the time when a client
close. I will rewrite the example replacing the client for socket:

func request(content) { ... }

let server = myserver()
while let *socket* = server.accept() {
  *autoreleasepool* {
*socket*.send(request(*socket*.read()))
*socket*.close()
  }
}


> Is `client` really getting autoreleased somewhere? autoreleasepool
> shouldn't normally be necessary. The client will be released when you go
> out of scope.
>
> -Joe
>



-- 
Nome : Bernardo Breder
Product : Breder Language
Site : bernardobreder.com
Email : bernardobre...@gmail.com
Email : bbre...@tecgraf.puc-rio.br
Email : cont...@bernardobreder.com
Graduação : UFF - Ciência da Computação
Mestrado : UFF - Ciência da Computação
Trabalho : TecGraf - PUC-RIO
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Autoreleasepool for Ubuntu

[Jens Alfke via swift-users]

> On Nov 2, 2016, at 1:42 PM, Bernardo Breder via swift-users 
>  wrote:
> 
> The algorithm that i send is a example of server code and this code will 
> execute in a ubuntu environment. When i install in the ubuntu, the swiftc 
> show me that the autoreleasepool is "use of unresolved identifier 
> 'autoreleasepool'". I want to clean the memory all the time when a client 
> close.

You don’t need to on Ubuntu. Autorelease pools are only to clean up Objective-C 
object references. Those don’t exist when you’re not running on an Apple 
platform; you only have Swift objects. 

That SO question you linked to is talking about code running on macOS or iOS. 
It doesn’t apply to other platforms.

—Jens

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

Re: [swift-users] Localization in Swift.

[Jens Alfke via swift-users]

> On Nov 2, 2016, at 12:50 PM, Dave Abrahams via swift-users 
>  wrote:
> 
> In my opinion, we can and must do much better for Swift.  If there's
> something about “%” formatting that you particularly value, I'd like to
> know about it, so I can make sure it's accomodated.

It offers more control over formatting, like min/max widths, number base, 
decimal places, etc. Yes, you can do this in the code inside the interpolated 
string, but IMHO it’s awkward because it requires knowing a bunch of extra 
methods for string conversion, truncation, etc. It’s a lot easier for me to 
remember and type “%x” than it is to remember and type the method that converts 
an int to a hex string.

Also (and more importantly for localization) the formatting details are part of 
the localizable format string, not hardwired. One example of this is formatting 
currency, where a US localization would use “$%.2f” but other currencies might 
call for more or fewer decimal places. There are other examples where one might 
swap format strings for other purposes like different-width layouts for 
monospaced/terminal output.

There’s also a nonstandard extension used by Cocoa/CF’s formatters, that allows 
the parameters to be reordered. (I haven’t used it so I don’t know the syntax 
offhand.) This is of course important for localization, to follow a language’s 
grammar.

I think these features could be added to interpolation. Just as a quick idea, 
maybe a syntax that allows formatting metacharacters to be added at the start 
of the interpolation, like “Please pay $\((.2) total)” where the “(.2) 
specifies two decimal places, or “The address is \((x) addr)”.

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

Re: [swift-users] Autoreleasepool for Ubuntu

[Jordan Rose via swift-users]

> On Nov 2, 2016, at 13:36, Joe Groff via swift-users  
> wrote:
> 
>> 
>> On Nov 2, 2016, at 1:16 PM, Bernardo Breder via swift-users 
>> > wrote:
>> 
>> In my http server i want to manager the memory all the time that we close a 
>> socket, like the example of manager in this link: 
>> http://stackoverflow.com/questions/25860942/is-it-necessary-to-use-autoreleasepool-in-a-swift-program
>>  
>> 
>> 
>> Algorithm that show the ideia:
>> 
>> func request(content) { ... }
>> 
>> let server = myserver()
>> while let client = server.accept() {
>>   autoreleasepool {
>> client.send(request(client.read()))
>> client.close()
>>   }
>> }
> 
> Is `client` really getting autoreleased somewhere? autoreleasepool shouldn't 
> normally be necessary. The client will be released when you go out of scope.

The problem is that on Apple platforms, the Foundation APIs used to implement 
the client autorelease things all over the place, so you need an autorelease 
pool somewhere to clean up the mess intermediate objects returned at +0.

Jordan

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

Re: [swift-users] Autoreleasepool for Ubuntu

[Joe Groff via swift-users]

> On Nov 2, 2016, at 1:16 PM, Bernardo Breder via swift-users 
>  wrote:
> 
> In my http server i want to manager the memory all the time that we close a 
> socket, like the example of manager in this link: 
> http://stackoverflow.com/questions/25860942/is-it-necessary-to-use-autoreleasepool-in-a-swift-program
>  
> 
> 
> Algorithm that show the ideia:
> 
> func request(content) { ... }
> 
> let server = myserver()
> while let client = server.accept() {
>   autoreleasepool {
> client.send(request(client.read()))
> client.close()
>   }
> }

Is `client` really getting autoreleased somewhere? autoreleasepool shouldn't 
normally be necessary. The client will be released when you go out of scope.

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

Re: [swift-users] Autoreleasepool for Ubuntu

[Bernardo Breder via swift-users]

In my http server i want to manager the memory all the time that we close a
socket, like the example of manager in this link:
http://stackoverflow.com/questions/25860942/is-it-necessary-to-use-autoreleasepool-in-a-swift-program

Algorithm that show the ideia:

*func request(content) { ... }*

*let server = myserver()*
*while let client = server.accept() {*
*  autoreleasepool {*
*client.send(request(client.read()))*
*client.close()*
*  }*
*}*

2016-11-02 18:08 GMT-02:00 Joe Groff :

>
> On Nov 2, 2016, at 1:00 PM, Philippe Hausler  wrote:
>
> See:
>
> https://github.com/apple/swift-corelibs-foundation/blob/
> d015466450b2675037c6f1ace8e17e73050ccfb9/Foundation/NSURL.swift#L561
>
> This is far and few between of cases that it would be useful but there are
> a few APIs that we have not been able to express without being able to
> autorelease items. Most of which we have either forbidden in Linux or
> redesigned because they were sub-par swift experiences. However it seems
> reasonable to have a minimal shim to provide cross platform code
> compatibility even if it does next to nothing. That way trivial code as the
> original issue showed can easily be directly compiled on either platform
> without littering gnarly #ifdefs about.
>
>
> In the fullness of time, the borrow model will hopefully give us a way to
> represent those kinds of "returns inner pointer" APIs safely in Swift
> without relying on dynamic lifetime extension, or awkward 'with { ... }'
> callbacks.
>
> -Joe
>



-- 
Nome : Bernardo Breder
Product : Breder Language
Site : bernardobreder.com
Email : bernardobre...@gmail.com
Email : bbre...@tecgraf.puc-rio.br
Email : cont...@bernardobreder.com
Graduação : UFF - Ciência da Computação
Mestrado : UFF - Ciência da Computação
Trabalho : TecGraf - PUC-RIO
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Autoreleasepool for Ubuntu

[Joe Groff via swift-users]

> On Nov 2, 2016, at 1:00 PM, Philippe Hausler  wrote:
> 
> See:
> 
> https://github.com/apple/swift-corelibs-foundation/blob/d015466450b2675037c6f1ace8e17e73050ccfb9/Foundation/NSURL.swift#L561
>  
> 
> 
> This is far and few between of cases that it would be useful but there are a 
> few APIs that we have not been able to express without being able to 
> autorelease items. Most of which we have either forbidden in Linux or 
> redesigned because they were sub-par swift experiences. However it seems 
> reasonable to have a minimal shim to provide cross platform code 
> compatibility even if it does next to nothing. That way trivial code as the 
> original issue showed can easily be directly compiled on either platform 
> without littering gnarly #ifdefs about.

In the fullness of time, the borrow model will hopefully give us a way to 
represent those kinds of "returns inner pointer" APIs safely in Swift without 
relying on dynamic lifetime extension, or awkward 'with { ... }' callbacks.

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

Re: [swift-users] Autoreleasepool for Ubuntu

[Jordan Rose via swift-users]

I don’t know, this isn’t really a good Swift API either. Some of the other bare 
pointer cases we changed to return arrays instead for this reason, like 
String’s version of cString(using:). 
https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/NSStringAPI.swift#L413

I am actually in favor of having a minimal shim, but I’d rather it do nothing 
like Joe’s case than to start allowing arbitrarily-delayed deinitialization 
like this.

Jordan


> On Nov 2, 2016, at 13:00, Philippe Hausler  wrote:
> 
> See:
> 
> https://github.com/apple/swift-corelibs-foundation/blob/d015466450b2675037c6f1ace8e17e73050ccfb9/Foundation/NSURL.swift#L561
>  
> 
> 
> This is far and few between of cases that it would be useful but there are a 
> few APIs that we have not been able to express without being able to 
> autorelease items. Most of which we have either forbidden in Linux or 
> redesigned because they were sub-par swift experiences. However it seems 
> reasonable to have a minimal shim to provide cross platform code 
> compatibility even if it does next to nothing. That way trivial code as the 
> original issue showed can easily be directly compiled on either platform 
> without littering gnarly #ifdefs about.
> 
>> On Nov 2, 2016, at 12:55 PM, Jordan Rose > > wrote:
>> 
>> I’m confused about this. Shouldn’t you be able to get away with using +1 
>> convention everywhere? What needs to have arbitrary lifetime-extension in an 
>> ARC-ified language?
>> 
>> Jordan
>> 
>>> On Nov 2, 2016, at 12:23, Philippe Hausler >> > wrote:
>>> 
>>> So there are issues we have in swift-corelibs that suffer(leak) because we 
>>> don't have ARPs on Linux. It would be super nice to have a retain until 
>>> scope end concept for swift core libs where autorelease would be an 
>>> accessor in unmanaged that would retain the object until the arp ends scope.
>>> 
>>> Sent from my iPhone
>>> 
>>> On Nov 2, 2016, at 10:17 AM, Jordan Rose >> > wrote:
>>> 
 
> On Nov 2, 2016, at 09:42, Joe Groff via swift-users 
> > wrote:
> 
>> 
>> On Nov 1, 2016, at 6:40 PM, Bernardo Breder via swift-users 
>> > wrote:
>> 
>> Hello,
>> 
>> I want to create a mini http server project and execute at Ubuntu 15. 
>> The Xcode compile and access the function "autoreleasepool", but when i 
>> compile the same code at Ubuntu, this function not found
>> 
>> For example, i can compile the code above at Xcode:
>> 
>> while true {
>>autoreleasepool {
>>var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
>> 1\r\n\r\na".data(using: .utf8)!
>>}
>> }
>> 
>> But when i try to compile at Ubuntu:
>> 
>> git@breder:~$ cat main.swift 
>> import Foundation
>> 
>> while true {
>>autoreleasepool {
>>var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
>> 1\r\n\r\na".data(using: .utf8)!
>>}
>> }
>> 
>> git@breder:~$ swiftc main.swift 
>> main.swift:4:5: error: use of unresolved identifier 'autoreleasepool'
>>autoreleasepool {
>>^~~
> 
> Autoreleasepools are an ObjC compatibility feature. They aren't necessary 
> in standalone Swift.
 
 But they are necessary in Swift programs on Apple platforms (that don’t 
 use RunLoop, anyway). Philippe, what do you think? What’s the right way to 
 write cross-platform code that doesn’t use RunLoop or dispatch_main for an 
 implicit autorelease pool?
 
 (/me remembers +[NSAutoreleasePool drain] from the ObjC-GC days)
 
 Jordan
>> 
> 

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

Re: [swift-users] What is "binding" memory?

[Dave Abrahams via swift-users]

on Tue Nov 01 2016, Andrew Trick  wrote:

>> On Nov 1, 2016, at 11:55 AM, Manfred Schubert via swift-users 
>>  wrote:
>> 
>> The "UnsafeRawPointer Migration" guide talks about "binding memory
>> to a type“ as if that was a well known term. I have never heard of
>> it yet though, and googling it returns no relevant results. I do not
>
>> understand what binding memory is supposed to do.
>> 
>> The migration guide says "Binding uninitialized memory to a type
>> prepares the memory to store values of that type“, but clearly raw
>> memory does not need to be prepared (and cannot be) to hold any
>> arbitrary type and value.
>> 
>> So what is this for, what does it actually do, and to whom is it done (the 
>> raw pointer, or the
> typed pointer which is returned, or the raw memory)?
>> 
>> 
>> Manfred
>
> Hi Manfred,
>
> At the top of the migration guide is a link to the memory model explanation:
> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#memory-model-explanation
>
> "A memory location's bound type is an abstract, dynamic property of the 
> memory used to formalize
> type safety.”
>
> I’m not sure I like the “prepares the memory” language myself. Binding
> memory communicates to the compiler that the memory locations are safe
> for typed access. Nothing happens at runtime--until someone writes a
> type safety sanitizer. 

Well, that's a slight overstatement IMO.  Sanitizers aside, the main
reason for these binding operations is that if you leave them out,
something different *will* happen at runtime... something that will make
your code do the wrong thing.

What I would say is that binding the memory has no immediate runtime
cost... but it's absolutely required if you want your program to behave
(and sometimes behaving correctly is a little slower than misbehaving).

> It affects the abstract state of the memory location, independent of
> the pointer variable used to access that memory. Binding memory
> returns a typed pointer for convenience and clarity, but there’s
> nothing special about that particular pointer value.
>
> Initialized memory is always bound to some type. A rawpointer can be
> used to access that memory without knowing its bound type.
>
> -Andy
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

-- 
-Dave

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

Re: [swift-users] Autoreleasepool for Ubuntu

[Philippe Hausler via swift-users]

See:

https://github.com/apple/swift-corelibs-foundation/blob/d015466450b2675037c6f1ace8e17e73050ccfb9/Foundation/NSURL.swift#L561
 


This is far and few between of cases that it would be useful but there are a 
few APIs that we have not been able to express without being able to 
autorelease items. Most of which we have either forbidden in Linux or 
redesigned because they were sub-par swift experiences. However it seems 
reasonable to have a minimal shim to provide cross platform code compatibility 
even if it does next to nothing. That way trivial code as the original issue 
showed can easily be directly compiled on either platform without littering 
gnarly #ifdefs about.

> On Nov 2, 2016, at 12:55 PM, Jordan Rose  wrote:
> 
> I’m confused about this. Shouldn’t you be able to get away with using +1 
> convention everywhere? What needs to have arbitrary lifetime-extension in an 
> ARC-ified language?
> 
> Jordan
> 
>> On Nov 2, 2016, at 12:23, Philippe Hausler > > wrote:
>> 
>> So there are issues we have in swift-corelibs that suffer(leak) because we 
>> don't have ARPs on Linux. It would be super nice to have a retain until 
>> scope end concept for swift core libs where autorelease would be an accessor 
>> in unmanaged that would retain the object until the arp ends scope.
>> 
>> Sent from my iPhone
>> 
>> On Nov 2, 2016, at 10:17 AM, Jordan Rose > > wrote:
>> 
>>> 
 On Nov 2, 2016, at 09:42, Joe Groff via swift-users > wrote:
 
> 
> On Nov 1, 2016, at 6:40 PM, Bernardo Breder via swift-users 
> > wrote:
> 
> Hello,
> 
> I want to create a mini http server project and execute at Ubuntu 15. The 
> Xcode compile and access the function "autoreleasepool", but when i 
> compile the same code at Ubuntu, this function not found
> 
> For example, i can compile the code above at Xcode:
> 
> while true {
>autoreleasepool {
>var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
> 1\r\n\r\na".data(using: .utf8)!
>}
> }
> 
> But when i try to compile at Ubuntu:
> 
> git@breder:~$ cat main.swift 
> import Foundation
> 
> while true {
>autoreleasepool {
>var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
> 1\r\n\r\na".data(using: .utf8)!
>}
> }
> 
> git@breder:~$ swiftc main.swift 
> main.swift:4:5: error: use of unresolved identifier 'autoreleasepool'
>autoreleasepool {
>^~~
 
 Autoreleasepools are an ObjC compatibility feature. They aren't necessary 
 in standalone Swift.
>>> 
>>> But they are necessary in Swift programs on Apple platforms (that don’t use 
>>> RunLoop, anyway). Philippe, what do you think? What’s the right way to 
>>> write cross-platform code that doesn’t use RunLoop or dispatch_main for an 
>>> implicit autorelease pool?
>>> 
>>> (/me remembers +[NSAutoreleasePool drain] from the ObjC-GC days)
>>> 
>>> Jordan
> 

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

Re: [swift-users] Autoreleasepool for Ubuntu

[Jordan Rose via swift-users]

I’m confused about this. Shouldn’t you be able to get away with using +1 
convention everywhere? What needs to have arbitrary lifetime-extension in an 
ARC-ified language?

Jordan

> On Nov 2, 2016, at 12:23, Philippe Hausler  wrote:
> 
> So there are issues we have in swift-corelibs that suffer(leak) because we 
> don't have ARPs on Linux. It would be super nice to have a retain until scope 
> end concept for swift core libs where autorelease would be an accessor in 
> unmanaged that would retain the object until the arp ends scope.
> 
> Sent from my iPhone
> 
> On Nov 2, 2016, at 10:17 AM, Jordan Rose  > wrote:
> 
>> 
>>> On Nov 2, 2016, at 09:42, Joe Groff via swift-users >> > wrote:
>>> 
 
 On Nov 1, 2016, at 6:40 PM, Bernardo Breder via swift-users 
 > wrote:
 
 Hello,
 
 I want to create a mini http server project and execute at Ubuntu 15. The 
 Xcode compile and access the function "autoreleasepool", but when i 
 compile the same code at Ubuntu, this function not found
 
 For example, i can compile the code above at Xcode:
 
 while true {
autoreleasepool {
var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
 1\r\n\r\na".data(using: .utf8)!
}
 }
 
 But when i try to compile at Ubuntu:
 
 git@breder:~$ cat main.swift 
 import Foundation
 
 while true {
autoreleasepool {
var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
 1\r\n\r\na".data(using: .utf8)!
}
 }
 
 git@breder:~$ swiftc main.swift 
 main.swift:4:5: error: use of unresolved identifier 'autoreleasepool'
autoreleasepool {
^~~
>>> 
>>> Autoreleasepools are an ObjC compatibility feature. They aren't necessary 
>>> in standalone Swift.
>> 
>> But they are necessary in Swift programs on Apple platforms (that don’t use 
>> RunLoop, anyway). Philippe, what do you think? What’s the right way to write 
>> cross-platform code that doesn’t use RunLoop or dispatch_main for an 
>> implicit autorelease pool?
>> 
>> (/me remembers +[NSAutoreleasePool drain] from the ObjC-GC days)
>> 
>> Jordan

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

Re: [swift-users] Localization in Swift.

[Dave Abrahams via swift-users]

on Tue Nov 01 2016, Jens Alfke  wrote:

>> On Nov 1, 2016, at 10:40 PM, Zhao Xin  wrote:
>> 
>> For example, if I want show the user that I have to ask him to give me 
>> permission of a folder, the
> `url.path` has no need to translate.
>
> We’re getting off-topic, but paths do need to be translated, at least
> on Mac systems. The names of many standard folders like “Applications”
> and “Documents” are hardwired to English in the filesystem but are
> localized in the UI. Some application names get localized too (there’s
> a table in the app’s Info.plist that can substitute localized names.)
>
> Anyway, string interpolation is convenient, but I wouldn’t say it
> should be the only way to format strings in Swift; it’s a lot less
> flexible than the C-style “%” substitutions. For comparison, even
> though C++’s iostreams use “<<“ to format strings by concatenation, I
> still end up using “%” based formatting a lot, depending on the use
> case.

I'm actually working on design in this area right now.

%-style formatting has the following drawbacks

- for anyone who doesn't use them regularly they are cryptic and
  complex, as the printf (3) man page attests.

- the spelling of these placeholders must match up to the types of the
  arguments, in the right order, or the behavior is undefined.  Some
  limited support for compile-time checking of this correspondence could
  be implemented, but only for the cases where the format string is a
  literal.

- there's no reasonable way to extend the formatting vocabulary to cover
  the needs of new types: you are stuck with what's in the box.

In my opinion, we can and must do much better for Swift.  If there's
something about “%” formatting that you particularly value, I'd like to
know about it, so I can make sure it's accomodated.

Thanks,

-- 
-Dave

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

[swift-users] wishing I could cast (sort of) to protocol with associated type

[Robert Nikander via swift-users]

Hi,

In the following code, I want to test if x is a `SpecialController`. If it is, 
I want to get the `currentValue` as a `SpecialValue`. How do you do this? If 
not with a cast, then some other technique.

I understand the error, and that SpecialController by itself is not a simple 
type to cast to. But it seems like what I’m saying is logically consistent and 
not that complicated. Is there really no way to *say* it in Swift?

protocol SpecialController {
associated type SpecialValueType : SpecialValue
var currentValue: SpecialValueType? { get }
}
...
var x: AnyObject = ...
if let sc = x as? SpecialController {  // does not compile

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

Re: [swift-users] Localization in Swift.

[Jens Alfke via swift-users]

> On Nov 2, 2016, at 11:23 AM, Marco S Hyman via swift-users 
>  wrote:
> 
> On Nov 1, 2016, at 11:42 PM, Zhao Xin via swift-users  
> wrote:
>> 
>> I have already give a workable implementation above.
> 
> Your implementation assume \(x) is always %@x.

It’s also not an implementation. It’s just an English-language sketch for how 
you might do it. “Implementation” means actual code. As programmers we all  
know that there are tons of details that don’t become apparent until you try to 
build a real program, and both Marco and I have pointed some out.

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

Re: [swift-users] Autoreleasepool for Ubuntu

[Bernardo Breder via swift-users]

I want to manager the memory, using the autoreleasepool block, with ubuntu
environment, as we can do with Xcode.

2016-11-02 15:34 GMT-02:00 Joe Groff :

>
> On Nov 2, 2016, at 10:17 AM, Jordan Rose  wrote:
>
>
> On Nov 2, 2016, at 09:42, Joe Groff via swift-users 
> wrote:
>
>
> On Nov 1, 2016, at 6:40 PM, Bernardo Breder via swift-users <
> swift-users@swift.org> wrote:
>
> Hello,
>
> I want to create a mini http server project and execute at Ubuntu 15. The
> Xcode compile and access the function "autoreleasepool", but when i compile
> the same code at Ubuntu, this function not found
>
> For example, i can compile the code above at Xcode:
>
> while true {
>autoreleasepool {
>var test: Data = "HTTP/1.1 200 OK\r\nContent-Length:
> 1\r\n\r\na".data(using: .utf8)!
>}
> }
>
> But when i try to compile at Ubuntu:
>
> git@breder:~$ cat main.swift
> import Foundation
>
> while true {
>autoreleasepool {
>var test: Data = "HTTP/1.1 200 OK\r\nContent-Length:
> 1\r\n\r\na".data(using: .utf8)!
>}
> }
>
> git@breder:~$ swiftc main.swift
> main.swift:4:5: error: use of unresolved identifier 'autoreleasepool'
>autoreleasepool {
>^~~
>
>
> Autoreleasepools are an ObjC compatibility feature. They aren't necessary
> in standalone Swift.
>
>
> But they *are* necessary in Swift programs on Apple platforms (that don’t
> use RunLoop, anyway). Philippe, what do you think? What’s the right way to
> write cross-platform code that doesn’t use RunLoop or dispatch_main for an
> implicit autorelease pool?
>
> (/me remembers +[NSAutoreleasePool drain] from the ObjC-GC days)
>
>
> If you must, you could conditionally define `autoreleasepool` to just call
> its argument as a compatibility shim.
>
> -Joe
>



-- 
Nome : Bernardo Breder
Product : Breder Language
Site : bernardobreder.com
Email : bernardobre...@gmail.com
Email : bbre...@tecgraf.puc-rio.br
Email : cont...@bernardobreder.com
Graduação : UFF - Ciência da Computação
Mestrado : UFF - Ciência da Computação
Trabalho : TecGraf - PUC-RIO
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] What is "binding" memory?

[Rien via swift-users]

> On 02 Nov 2016, at 18:07, Manfred Schubert via swift-users 
>  wrote:
> 
> Am 01.11.2016 um 21:40 schrieb Andrew Trick :
>> 
>> I’m not sure I like the “prepares the memory” language myself. Binding 
>> memory communicates to the compiler that the memory locations are safe for 
>> typed access. Nothing happens at runtime--until someone writes a type safety 
>> sanitizer.
> 
> So nothing happens at runtime, and also nothing appears to happen at compile 
> time. If I try this code:
> 
>> var rawPtr = UnsafeMutableRawPointer.allocate(bytes: 2, alignedTo: 0)
>> 
>> var widePtr = rawPtr.bindMemory(to: Int16.self, capacity: 1)
>> 
>> widePtr.pointee = 32
>> 
>> var narrowPtr = rawPtr.bindMemory(to: UInt8.self, capacity: 2)
>> 
>> narrowPtr[0] = 16
>> narrowPtr[1] = 255
>> 
>> print(widePtr.pointee)
> 
> This compiles and runs as expected, but it should not be allowed if I 
> understand things correctly. So shouldn’t it be a compile time error or crash 
> at runtime? If not, what do I get over how it was before where I was casting 
> to a typed pointer?

Why do you think it should not be allowed.
AFAICS everything is correct.
Are you referring to the multiple interpretation of the raw memory? That is 
entirely intentional, indeed one of the main purposes.

Rien.

> 
>> It affects the abstract state of the memory location, independent of the 
>> pointer variable used to access that memory. Binding memory returns a typed 
>> pointer for convenience and clarity, but there’s nothing special about that 
>> particular pointer value.
> 
> If it were not returning a typed pointer, what would it actually do?
> 
> 
> Manfred
> ___
> 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] Autoreleasepool for Ubuntu

[Joe Groff via swift-users]

> On Nov 2, 2016, at 10:17 AM, Jordan Rose  wrote:
> 
>> 
>> On Nov 2, 2016, at 09:42, Joe Groff via swift-users > > wrote:
>> 
>>> 
>>> On Nov 1, 2016, at 6:40 PM, Bernardo Breder via swift-users 
>>> > wrote:
>>> 
>>> Hello,
>>> 
>>> I want to create a mini http server project and execute at Ubuntu 15. The 
>>> Xcode compile and access the function "autoreleasepool", but when i compile 
>>> the same code at Ubuntu, this function not found
>>> 
>>> For example, i can compile the code above at Xcode:
>>> 
>>> while true {
>>>autoreleasepool {
>>>var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
>>> 1\r\n\r\na".data(using: .utf8)!
>>>}
>>> }
>>> 
>>> But when i try to compile at Ubuntu:
>>> 
>>> git@breder:~$ cat main.swift 
>>> import Foundation
>>> 
>>> while true {
>>>autoreleasepool {
>>>var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
>>> 1\r\n\r\na".data(using: .utf8)!
>>>}
>>> }
>>> 
>>> git@breder:~$ swiftc main.swift 
>>> main.swift:4:5: error: use of unresolved identifier 'autoreleasepool'
>>>autoreleasepool {
>>>^~~
>> 
>> Autoreleasepools are an ObjC compatibility feature. They aren't necessary in 
>> standalone Swift.
> 
> But they are necessary in Swift programs on Apple platforms (that don’t use 
> RunLoop, anyway). Philippe, what do you think? What’s the right way to write 
> cross-platform code that doesn’t use RunLoop or dispatch_main for an implicit 
> autorelease pool?
> 
> (/me remembers +[NSAutoreleasePool drain] from the ObjC-GC days)

If you must, you could conditionally define `autoreleasepool` to just call its 
argument as a compatibility shim.

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

Re: [swift-users] Autoreleasepool for Ubuntu

[Jordan Rose via swift-users]

> On Nov 2, 2016, at 09:42, Joe Groff via swift-users  
> wrote:
> 
>> 
>> On Nov 1, 2016, at 6:40 PM, Bernardo Breder via swift-users 
>>  wrote:
>> 
>> Hello,
>> 
>> I want to create a mini http server project and execute at Ubuntu 15. The 
>> Xcode compile and access the function "autoreleasepool", but when i compile 
>> the same code at Ubuntu, this function not found
>> 
>> For example, i can compile the code above at Xcode:
>> 
>> while true {
>>autoreleasepool {
>>var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
>> 1\r\n\r\na".data(using: .utf8)!
>>}
>> }
>> 
>> But when i try to compile at Ubuntu:
>> 
>> git@breder:~$ cat main.swift 
>> import Foundation
>> 
>> while true {
>>autoreleasepool {
>>var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
>> 1\r\n\r\na".data(using: .utf8)!
>>}
>> }
>> 
>> git@breder:~$ swiftc main.swift 
>> main.swift:4:5: error: use of unresolved identifier 'autoreleasepool'
>>autoreleasepool {
>>^~~
> 
> Autoreleasepools are an ObjC compatibility feature. They aren't necessary in 
> standalone Swift.

But they are necessary in Swift programs on Apple platforms (that don’t use 
RunLoop, anyway). Philippe, what do you think? What’s the right way to write 
cross-platform code that doesn’t use RunLoop or dispatch_main for an implicit 
autorelease pool?

(/me remembers +[NSAutoreleasePool drain] from the ObjC-GC days)

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

Re: [swift-users] What is "binding" memory?

[Manfred Schubert via swift-users]

Am 01.11.2016 um 21:40 schrieb Andrew Trick :
> 
> I’m not sure I like the “prepares the memory” language myself. Binding memory 
> communicates to the compiler that the memory locations are safe for typed 
> access. Nothing happens at runtime--until someone writes a type safety 
> sanitizer.

So nothing happens at runtime, and also nothing appears to happen at compile 
time. If I try this code:

> var rawPtr = UnsafeMutableRawPointer.allocate(bytes: 2, alignedTo: 0)
> 
> var widePtr = rawPtr.bindMemory(to: Int16.self, capacity: 1)
> 
> widePtr.pointee = 32
> 
> var narrowPtr = rawPtr.bindMemory(to: UInt8.self, capacity: 2)
> 
> narrowPtr[0] = 16
> narrowPtr[1] = 255
> 
> print(widePtr.pointee)

This compiles and runs as expected, but it should not be allowed if I 
understand things correctly. So shouldn’t it be a compile time error or crash 
at runtime? If not, what do I get over how it was before where I was casting to 
a typed pointer?

> It affects the abstract state of the memory location, independent of the 
> pointer variable used to access that memory. Binding memory returns a typed 
> pointer for convenience and clarity, but there’s nothing special about that 
> particular pointer value.

If it were not returning a typed pointer, what would it actually do?


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

Re: [swift-users] Autoreleasepool for Ubuntu

[Joe Groff via swift-users]

> On Nov 1, 2016, at 6:40 PM, Bernardo Breder via swift-users 
>  wrote:
> 
> Hello,
> 
> I want to create a mini http server project and execute at Ubuntu 15. The 
> Xcode compile and access the function "autoreleasepool", but when i compile 
> the same code at Ubuntu, this function not found
> 
> For example, i can compile the code above at Xcode:
> 
> while true {
> autoreleasepool {
> var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
> 1\r\n\r\na".data(using: .utf8)!
> }
> }
> 
> But when i try to compile at Ubuntu:
> 
> git@breder:~$ cat main.swift 
> import Foundation
> 
> while true {
> autoreleasepool {
> var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
> 1\r\n\r\na".data(using: .utf8)!
> }
> }
> 
> git@breder:~$ swiftc main.swift 
> main.swift:4:5: error: use of unresolved identifier 'autoreleasepool'
> autoreleasepool {
> ^~~

Autoreleasepools are an ObjC compatibility feature. They aren't necessary in 
standalone Swift.

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

Re: [swift-users] Localization in Swift.

[Jens Alfke via swift-users]

> On Nov 1, 2016, at 10:56 PM, Zhao Xin  wrote:
> 
> I am not talking to eliminate "%" style function. I am talking to add more 
> compatibility to `NSLocalizedString` with `\(foo)` style.

I don’t think the ExpressibleByStringInterpolation protocol provides enough 
information to make this work. It hands the implementation a list of values to 
concatenate, some of which are strings, but as far as I can tell there’s no way 
to tell which of those strings are the pieces of the string literal and which 
of them are the results of expressions. So NSLocalizedString would not be able 
to reassemble the string template that you gave it, to look up in the 
localization table.

If I’m wrong about this, show me a workable implementation of it. :)

Also, ExpressibleByStringInterpolation is marked as being deprecated and will 
be “replaced or redesigned in Swift 4.0.” Maybe to solve this limitation?

—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

[Jens Alfke via swift-users]

> On Nov 1, 2016, at 9:50 PM, Shyamal Chandra via swift-users 
>  wrote:
> 
> Why don't you make the Playgrounds open source so I can investigate? 

I’ve been hearing people tell Apple “why don’t you make ___ open source” for as 
long as the term ‘open source’ has existed. Sometimes it happens, but the 
decision doesn’t seem to be based on factors like ‘people on the Internet are 
yelling at us to open-source this’, or ‘this feature sucks, let’s dump the 
source code on Github and let volunteers fix it for us for free!’

I’m being sarcastic here, but if you’d ever run an open source project — or 
worse, open-sourced an existing code base — you’d have some idea of the 
complexity of what you’re asking. Open source is a commitment, and it can be a 
ton of work just getting the code ready, especially when it has dependencies on 
private APIs from other components that shouldn’t be exposed. Even comments and 
identifiers need to be scrubbed of references to internal/secret/embarrassing 
information, like “// we’re commenting out this feature until the 2017 Mac Pro 
ships in March”, or “// Workaround to make Photoshop compile, no thanks to 
those morons at Adobe”. (Yes, I went through stuff like this in one project in 
the ‘90s.)

As for Playgrounds, I’m not aware of Apple open-sourcing GUI-level application 
code. Ever. (Someone correct me if I’ve forgotten something.)

> You should tell this to Tim Cook as soon as possible.

Because everyone at Apple is on a first-name basis with Tim Cook and feels free 
to drop into his office and tell him what to do.  Back when I worked at Apple 
I used to drop in on Steve and tell him the metal UI appearance sucked. He’d 
chuckle in his kindly way, and then nail my head to the floor.

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