[swift-users] TWISt-shout Newsletter 2017-05-08

[Kenny Leung via swift-users]

Hi All.

Here is your TWISt-shout Newsletter for the week of 2017-05-01 to 2017-05-07

https://github.com/pepperdog/TWISt-shout/blob/master/2017/TWISt-shout-2017-05-08.md
 


Enjoy!

-Kenny


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

Re: [swift-users] Swift build-script Smaller Memory Footprint?

[Brandon B via swift-users]

Prior to the script hanging, I see the following:

> ninja: no work to do
> llvm: using gold linker

Presumably that means I am using gold, correct?
> On May 6, 2017, at 9:21 PM, Brandon B  wrote:
> 
> Hello,
> 
> I’m installing Swift 3 on FreeBSD 11. After installing the necessary 
> dependencies, I now only need to run the build-script.
> 
> The problem is that I cannot proceed beyond:
> 
> >  Linking CXX executable bin/llvm-lto
> 
> because I consistently run out of memory on my 16GB server.
> 
> From what I’ve gathered, the problem lies in  ld  which is apparently 
> infamous for this sort of behavior.
> 
> I know that I can run ld without debug options (which would reduce its memory 
> footprint dramatically) but I don’t know how I would do that, given that it 
> is called by the build-script.
> 
> What do I need to do to make the build-script use less memory?
> 
> — Brandon Bradley

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

Re: [swift-users] Swift build-script Smaller Memory Footprint?

[Slava Pestov via swift-users]

On Darwin (which uses its own linker and not GNU ld), you can definitely build 
Swift with less than 16GB of RAM available.

Maybe you could try gold?

Slava

> On May 6, 2017, at 7:21 PM, Brandon B via swift-users  
> wrote:
> 
> Hello,
> 
> I’m installing Swift 3 on FreeBSD 11. After installing the necessary 
> dependencies, I now only need to run the build-script.
> 
> The problem is that I cannot proceed beyond:
> 
> >  Linking CXX executable bin/llvm-lto
> 
> because I consistently run out of memory on my 16GB server.
> 
> From what I’ve gathered, the problem lies in  ld  which is apparently 
> infamous for this sort of behavior.
> 
> I know that I can run ld without debug options (which would reduce its memory 
> footprint dramatically) but I don’t know how I would do that, given that it 
> is called by the build-script.
> 
> What do I need to do to make the build-script use less memory?
> 
> — Brandon Bradley
> ___
> 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] Annotating C APIs without changing the original header files

[Geordie Jay via swift-users]

I'm having the same issue. The renames seem to work, as in they disappear
from the global scope with a fixit to rename to the new (namespaced)
version if I type in the name manually, but they don't appear as static
members of the enum type, regardless of how I call them. Would appreciate
some help with this too.

Cheers,
Geordie
Rick Mann  schrieb am So. 7. Mai 2017 um 23:06:

> I'm trying to use apinotes for this third-party C library (call it
> "Lib.dylib"). It has an enum lgs_error_t:
>
> typedef enum {
> lgs_error_none = 0,
> lgs_error_invalid_handle = -1,
> lgs_error_null = -2,
> lgs_error_invalid_parameter = -3,
> lgs_error_invalid_operation = -4,
> lgs_error_queue_full = -5
> } lgs_error_t;
>
> So I wrote apinotes ("Lib.apinotes") that look like this, next to the
> .dylib, and part of my Xcode iOS app target:
>
> Enumerators:
> # lgs_error_t
>
> - Name: lgs_error_none
>   SwiftName: lgs_error_t.none
> - Name: lgs_error_invalid_handle
>   SwiftName: lgs_error_t.invalidHandle
> - Name: lgs_error_null
>   SwiftName: lgs_error_t.nullParameter
> - Name: lgs_error_invalid_parameter
>   SwiftName: lgs_error_t.invalideParameter
> - Name: lgs_error_invalid_operation
>   SwiftName: lgs_error_t.invalidOperation
> - Name: lgs_error_queue_full
>   SwiftName: lgs_error_t.queueFull
>
> But this line of code fails:
>
> var err: lgs_error_t = .nullParameter
> Type 'lgs_error_t' has no member 'nullParameter'
>
> Am I missing something else?
>
> > On May 4, 2017, at 16:55 , Douglas Gregor via swift-users <
> swift-users@swift.org> wrote:
> >
> >
> >> On May 3, 2017, at 4:10 PM, Geordie J via swift-users <
> swift-users@swift.org> wrote:
> >>
> >> Hi everyone,
> >>
> >> I’m about to start on another big project with Swift on Android and
> would like to annotate that JNI headers as much as possible before I do:
> specifically I’d like to make _Nonnull and CF_SWIFT_NAME annotations to the
> headers found in a user's jni.h.
> >>
> >> The question is: is it possible to annotate headers this without
> changing the original header files? Specifically I’m looking for an options
> that allows annotations in a separate file, probably one that is read when
> loading the package’s module.modulemap.
> >>
> >> I’d like to distribute the annotations in a SwiftPM package that also
> exposes the original (hopefully annotated) headers. Up until now I’ve been
> using Swift to override methods in code, but this isn’t as clean or
> extensible and I fear it may have other (particularly performance)
> implications.
> >>
> >> I guess the alternative would be to just maintain and distribute a
> modified version of jni.h with the annotations, but that would be a "last
> resort” option.
> >
> >
> > This is the role of API notes, which you can see here:
> >
> >   https://github.com/apple/swift/tree/master/apinotes
> >
> > with some rough documentation-in-source here:
> >
> >
> https://github.com/apple/swift-clang/blob/stable/lib/APINotes/APINotesYAMLCompiler.cpp
> >
> >   - Doug
> >
> > ___
> > 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] Annotating C APIs without changing the original header files

[Rick Mann via swift-users]

I'm trying to use apinotes for this third-party C library (call it 
"Lib.dylib"). It has an enum lgs_error_t:

typedef enum {
lgs_error_none = 0,
lgs_error_invalid_handle = -1,
lgs_error_null = -2,
lgs_error_invalid_parameter = -3,
lgs_error_invalid_operation = -4,
lgs_error_queue_full = -5
} lgs_error_t;

So I wrote apinotes ("Lib.apinotes") that look like this, next to the .dylib, 
and part of my Xcode iOS app target:

Enumerators:
# lgs_error_t

- Name: lgs_error_none
  SwiftName: lgs_error_t.none
- Name: lgs_error_invalid_handle
  SwiftName: lgs_error_t.invalidHandle
- Name: lgs_error_null
  SwiftName: lgs_error_t.nullParameter
- Name: lgs_error_invalid_parameter
  SwiftName: lgs_error_t.invalideParameter
- Name: lgs_error_invalid_operation
  SwiftName: lgs_error_t.invalidOperation
- Name: lgs_error_queue_full
  SwiftName: lgs_error_t.queueFull

But this line of code fails:

var err: lgs_error_t = .nullParameter
Type 'lgs_error_t' has no member 'nullParameter'

Am I missing something else?

> On May 4, 2017, at 16:55 , Douglas Gregor via swift-users 
>  wrote:
> 
> 
>> On May 3, 2017, at 4:10 PM, Geordie J via swift-users 
>>  wrote:
>> 
>> Hi everyone,
>> 
>> I’m about to start on another big project with Swift on Android and would 
>> like to annotate that JNI headers as much as possible before I do: 
>> specifically I’d like to make _Nonnull and CF_SWIFT_NAME annotations to the 
>> headers found in a user's jni.h.
>> 
>> The question is: is it possible to annotate headers this without changing 
>> the original header files? Specifically I’m looking for an options that 
>> allows annotations in a separate file, probably one that is read when 
>> loading the package’s module.modulemap.
>> 
>> I’d like to distribute the annotations in a SwiftPM package that also 
>> exposes the original (hopefully annotated) headers. Up until now I’ve been 
>> using Swift to override methods in code, but this isn’t as clean or 
>> extensible and I fear it may have other (particularly performance) 
>> implications.
>> 
>> I guess the alternative would be to just maintain and distribute a modified 
>> version of jni.h with the annotations, but that would be a "last resort” 
>> option.
> 
> 
> This is the role of API notes, which you can see here:
> 
>   https://github.com/apple/swift/tree/master/apinotes
> 
> with some rough documentation-in-source here:
> 
>   
> https://github.com/apple/swift-clang/blob/stable/lib/APINotes/APINotesYAMLCompiler.cpp
> 
>   - Doug
> 
> ___
> 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] Passing value types or members of value types?

[Kelvin Ma via swift-users]

i’m also curious as to whether this would be faster as a member function on the 
struct itself, since member functions get `self` as a pointer, right?

> On May 7, 2017, at 11:21 AM, Kelvin Ma  wrote:
> 
> So if I am passing the large struct to a large function, or a function that 
> lives in a different module (as my project is currently split into 8 or 9 
> modules — is that too many?), am I better off passing the members 
> individually instead of passing the entire struct? It seems kind of tedious 
> to have to write 
> 
> func f(x:Double, y:Double) -> Double 
> {
> 
> }
> 
> let z:Double = f(x: point.x, y: point.y) 
> 
> instead, and it seems like something the compiler ought to be responsible for.
> 
> Also about boxing the struct, isn’t that the worst of both worlds? You get 
> the overhead of pass-by-value, the overhead of reference counting, the heap 
> allocation, and the heap access. Plus it’s a lot of work to manually 
> implement copy on write, and the copy is decided at runtime, even when it is 
> known that an object will or won’t be mutated at compile time. 
> 
>> On Sun, May 7, 2017 at 12:43 AM, Daniel Dunbar  
>> wrote:
>> 
 On May 6, 2017, at 10:39 PM, Brent Royal-Gordon  
 wrote:
 
 On May 6, 2017, at 10:34 PM, Daniel Dunbar via swift-users 
  wrote:
 
 To answer Kelvin's question, yes, the optimizer will be able to see 
 through that code _assuming_ it can see the definition in a way it can 
 optimize
>>> 
>>> 
>>> Kelvin, you should definitely take Daniel's word over mine on whether 
>>> there's an optimization for this. I believe the rest of my explanation is 
>>> correct.
>> 
>> Actually I think yours was more accurate... while it is is true the desired 
>> optimization will often take effect (given the conditions I describe), 
>> your's was correct that this isn't happening because the function signature 
>> is taking _fewer_ arguments. Rather, the optimizations works because the 
>> compiler will tend to inline that small function and then see it can discard 
>> the unnecessary data.
>> 
>> Whether or not this makes it worth boxing your struct to avoid large copies 
>> probably depends on how much you need to pass the struct through call sites 
>> which would in fact need to copy the full struct, versus inlining down to 
>> something smaller.
>> 
>> HTH,
>>  - Daniel
>> 
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>> 
> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Passing value types or members of value types?

[Kelvin Ma via swift-users]

copy on write is not intrinsic to structs, is it? I believe copy on write
is implemented in Array because Array contains a class for its storage,
which checks its own reference count when it is mutated, and String gets
the same behavior because String uses an Array as its underlying storage.

On Sun, May 7, 2017 at 11:57 AM, Zhao Xin  wrote:

> I don't tend to think all of this unless there has been already a
> noticeable speed drop. So my question is, is there a noticeable drop for
> you?
>
> For your question, in my knowledge, if your function only uses/reads the
> struct's value, there is no copy in memory. It is called copy on write. The
> copy won't happen until you write to the copy (mutate the struct's
> properties). So if your function never mutates the struct, the speed should
> be very alike as you are using classes.
>
> Zhaoxin
>
>
>
> On Mon, May 8, 2017 at 12:21 AM, Kelvin Ma via swift-users <
> swift-users@swift.org> wrote:
>
>> So if I am passing the large struct to a large function, or a function
>> that lives in a different module (as my project is currently split into 8
>> or 9 modules — is that too many?), am I better off passing the members
>> individually instead of passing the entire struct? It seems kind of tedious
>> to have to write
>>
>> func f(x:Double, y:Double) -> Double
>> {
>> 
>> }
>>
>> let z:Double = f(x: point.x, y: point.y)
>>
>> instead, and it seems like something the compiler ought to be responsible
>> for.
>>
>> Also about boxing the struct, isn’t that the worst of both worlds? You
>> get the overhead of pass-by-value, the overhead of reference counting, the
>> heap allocation, and the heap access. Plus it’s a lot of work to manually
>> implement copy on write, and the copy is decided at runtime, even when it
>> is known that an object will or won’t be mutated at compile time.
>>
>> On Sun, May 7, 2017 at 12:43 AM, Daniel Dunbar 
>> wrote:
>>
>>>
>>> On May 6, 2017, at 10:39 PM, Brent Royal-Gordon 
>>> wrote:
>>>
>>> On May 6, 2017, at 10:34 PM, Daniel Dunbar via swift-users <
>>> swift-users@swift.org> wrote:
>>>
>>> To answer Kelvin's question, yes, the optimizer will be able to see
>>> through that code _assuming_ it can see the definition in a way it can
>>> optimize
>>>
>>>
>>> Kelvin, you should definitely take Daniel's word over mine on whether
>>> there's an optimization for this. I believe the rest of my explanation is
>>> correct.
>>>
>>>
>>> Actually I think yours was more accurate... while it is is true the
>>> desired optimization will often take effect (given the conditions I
>>> describe), your's was correct that this isn't happening because the
>>> function signature is taking _fewer_ arguments. Rather, the optimizations
>>> works because the compiler will tend to inline that small function and then
>>> see it can discard the unnecessary data.
>>>
>>> Whether or not this makes it worth boxing your struct to avoid large
>>> copies probably depends on how much you need to pass the struct through
>>> call sites which would in fact need to copy the full struct, versus
>>> inlining down to something smaller.
>>>
>>> HTH,
>>>  - Daniel
>>>
>>>
>>> --
>>> Brent Royal-Gordon
>>> Architechies
>>>
>>>
>>>
>>
>> ___
>> 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] Passing value types or members of value types?

[Kelvin Ma via swift-users]

So if I am passing the large struct to a large function, or a function that
lives in a different module (as my project is currently split into 8 or 9
modules — is that too many?), am I better off passing the members
individually instead of passing the entire struct? It seems kind of tedious
to have to write

func f(x:Double, y:Double) -> Double
{

}

let z:Double = f(x: point.x, y: point.y)

instead, and it seems like something the compiler ought to be responsible
for.

Also about boxing the struct, isn’t that the worst of both worlds? You get
the overhead of pass-by-value, the overhead of reference counting, the heap
allocation, and the heap access. Plus it’s a lot of work to manually
implement copy on write, and the copy is decided at runtime, even when it
is known that an object will or won’t be mutated at compile time.

On Sun, May 7, 2017 at 12:43 AM, Daniel Dunbar 
wrote:

>
> On May 6, 2017, at 10:39 PM, Brent Royal-Gordon 
> wrote:
>
> On May 6, 2017, at 10:34 PM, Daniel Dunbar via swift-users <
> swift-users@swift.org> wrote:
>
> To answer Kelvin's question, yes, the optimizer will be able to see
> through that code _assuming_ it can see the definition in a way it can
> optimize
>
>
> Kelvin, you should definitely take Daniel's word over mine on whether
> there's an optimization for this. I believe the rest of my explanation is
> correct.
>
>
> Actually I think yours was more accurate... while it is is true the
> desired optimization will often take effect (given the conditions I
> describe), your's was correct that this isn't happening because the
> function signature is taking _fewer_ arguments. Rather, the optimizations
> works because the compiler will tend to inline that small function and then
> see it can discard the unnecessary data.
>
> Whether or not this makes it worth boxing your struct to avoid large
> copies probably depends on how much you need to pass the struct through
> call sites which would in fact need to copy the full struct, versus
> inlining down to something smaller.
>
> HTH,
>  - Daniel
>
>
> --
> Brent Royal-Gordon
> Architechies
>
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users