Re: [swift-users] Annotating C APIs without changing the original header files

[Daniel Dunbar via swift-users]

We don't have explicit support for api notes in SwiftPM.

We discussed it, and it something which probably makes sense, but no one has 
worked on a design or implementation yet.

 - Daniel

> On May 12, 2017, at 11:32 AM, Michael Gottesman via swift-users 
>  wrote:
> 
> +Ankit
> 
> Michael
> 
>> On May 12, 2017, at 10:10 AM, Geordie J via swift-users 
>> > wrote:
>> 
>> To continue this thread: I managed to annotate a bunch of C APIs with 
>> modulename.apinotes. This works with Xcode (to a certain degree - pointers, 
>> enums, and especially OpaquePointers are tricky). I’m now trying to build my 
>> package with SwiftPM and it doesn’t seem to recognise the apinotes file. 
>> 
>> @Doug Gregor, would you be able to advise as to whether apinotes works with 
>> SwiftPM (on Linux) and whether it requires some extra settings that I may be 
>> unaware of?
>> 
>> Thanks and best regards for the weekend,
>> Geordie
>> 
>> 
>>> Am 08.05.2017 um 00:51 schrieb Geordie Jay >> >:
>>> 
>>> 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 
>>> > > 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
>>> 

Re: [swift-users] Annotating C APIs without changing the original header files

[Geordie J via swift-users]

To continue this thread: I managed to annotate a bunch of C APIs with 
modulename.apinotes. This works with Xcode (to a certain degree - pointers, 
enums, and especially OpaquePointers are tricky). I’m now trying to build my 
package with SwiftPM and it doesn’t seem to recognise the apinotes file. 

@Doug Gregor, would you be able to advise as to whether apinotes works with 
SwiftPM (on Linux) and whether it requires some extra settings that I may be 
unaware of?

Thanks and best regards for the weekend,
Geordie


> Am 08.05.2017 um 00:51 schrieb Geordie Jay :
> 
> 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 
> > > 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] Splitting a string into "natural/visual character" components?

[Jens Persson via swift-users]

Ah, thanks!

On Fri, May 12, 2017 at 11:45 AM, Martin R  wrote:

> The enumerateSubstrings method of (NS)String has a
> .byComposedCharacterSequences option which causes Emoji sequences like
> "‍‍‍" to be treated as a single unit:
>
> func f(_ s: String) -> [String] {
> var a: [String] = []
> s.enumerateSubstrings(in: s.startIndex.. byComposedCharacterSequences) {
> (c, _, _, _) in
> if let c = c { a.append(c) }
> }
> return a
> }
>
> print(f("‍‍‍‍♀️")) // ["‍‍‍", "‍♀️"]
>
>
> As I understand it from https://oleb.net/blog/2016/12/emoji-4-0/, Emoji
> sequences are considered as a single grapheme cluster in Unicode 9, which
> means that you can simply do something like
>
> Array("‍‍‍‍♀️".characters)
>
> once Unicode 9 is adopted in Swift.
>
> Regards, Martin
>
>
> On 12. May 2017, at 10:43, Jens Persson via swift-users <
> swift-users@swift.org> wrote:
>
> I want a function f such that:
>
> f("abc") == ["a", "b", "c"]
>
> f("café") == ["c", "a", "f", "é"]
>
> f("‍‍‍‍♀️") == ["‍‍‍", "‍♀️"]
>
> I'm not sure if the last example renders correctly by mail for everyone
> but the input String contains these _two_ "natural/visual characters":
> (1) A family emoji
> (2) a construction worker (woman, with skin tone modifier) emoji.
> and the result is an Array of two strings (one for each emoji).
>
> The first two examples are easy, the third example is the tricky one.
>
> Is there a (practical) way to do this (in Swift 3)?
>
> /Jens
>
>
>
> PS
>
> It's OK if the function has to depend on eg a graphics context etc.
> (I tried writing a function so that it extracts the glyphs, using
> NSTextStorage, NSLayoutManager and the AppleColorEmoji font, but it says
> that "‍‍‍‍♀️" contains 18(!) glyphs, whereas eg "café" contains
> 4 as expected.)
>
> If the emojis of the third example doesn't look like they should in this
> mail, here is another way to write the exact same example using only simple
> text:
>
> let inputOfThirdExample = "\u{1F468}\u{200D}\u{1F469}\u{
> 200D}\u{1F467}\u{200D}\u{1F466}\u{1F477}\u{1F3FE}\u{200D}\u{2640}\u{FE0F}"
>
> let result = f(inputOfThirdExample)
>
> let expectedResult = ["\u{1F468}\u{200D}\u{1F469}\
> u{200D}\u{1F467}\u{200D}\u{1F466}", "\u{1F477}\u{1F3FE}\u{200D}\u{
> 2640}\u{FE0F}"]
>
> print(result.elementsEqual(result)) // Should print true
>
>
> ___
> 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] Splitting a string into "natural/visual character" components?

[Martin R via swift-users]

The enumerateSubstrings method of (NS)String has a 
.byComposedCharacterSequences option which causes Emoji sequences like 
"‍‍‍" to be treated as a single unit:

func f(_ s: String) -> [String] {
var a: [String] = []
s.enumerateSubstrings(in: s.startIndex.., Emoji sequences are considered as a 
single grapheme cluster in Unicode 9, which means that you can simply do 
something like

Array("‍‍‍‍♀️".characters)

once Unicode 9 is adopted in Swift.

Regards, Martin


> On 12. May 2017, at 10:43, Jens Persson via swift-users 
>  wrote:
> 
> I want a function f such that:
> 
> f("abc") == ["a", "b", "c"]
> 
> f("café") == ["c", "a", "f", "é"]
> 
> f("‍‍‍‍♀️") == ["‍‍‍", "‍♀️"]
> 
> I'm not sure if the last example renders correctly by mail for everyone but 
> the input String contains these _two_ "natural/visual characters":
> (1) A family emoji
> (2) a construction worker (woman, with skin tone modifier) emoji.
> and the result is an Array of two strings (one for each emoji).
> 
> The first two examples are easy, the third example is the tricky one.
> 
> Is there a (practical) way to do this (in Swift 3)?
> 
> /Jens
> 
> 
> 
> PS
> 
> It's OK if the function has to depend on eg a graphics context etc.
> (I tried writing a function so that it extracts the glyphs, using 
> NSTextStorage, NSLayoutManager and the AppleColorEmoji font, but it says that 
> "‍‍‍‍♀️" contains 18(!) glyphs, whereas eg "café" contains 4 as 
> expected.)
> 
> If the emojis of the third example doesn't look like they should in this 
> mail, here is another way to write the exact same example using only simple 
> text:
> 
> let inputOfThirdExample = 
> "\u{1F468}\u{200D}\u{1F469}\u{200D}\u{1F467}\u{200D}\u{1F466}\u{1F477}\u{1F3FE}\u{200D}\u{2640}\u{FE0F}"
> 
> let result = f(inputOfThirdExample)
> 
> let expectedResult = 
> ["\u{1F468}\u{200D}\u{1F469}\u{200D}\u{1F467}\u{200D}\u{1F466}", 
> "\u{1F477}\u{1F3FE}\u{200D}\u{2640}\u{FE0F}"]
> 
> print(result.elementsEqual(result)) // Should print true
> 
> 
> ___
> 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] Splitting a string into "natural/visual character" components?

[Jens Persson via swift-users]

FWIW: I can conclude that the third example does not render correctly in
Gmail ...

On Fri, May 12, 2017 at 10:43 AM, Jens Persson  wrote:

> I want a function f such that:
>
> f("abc") == ["a", "b", "c"]
>
> f("café") == ["c", "a", "f", "é"]
>
> f("‍‍‍‍♀️") == ["‍‍‍", "‍♀️"]
>
> I'm not sure if the last example renders correctly by mail for everyone
> but the input String contains these _two_ "natural/visual characters":
> (1) A family emoji
> (2) a construction worker (woman, with skin tone modifier) emoji.
> and the result is an Array of two strings (one for each emoji).
>
> The first two examples are easy, the third example is the tricky one.
>
> Is there a (practical) way to do this (in Swift 3)?
>
> /Jens
>
>
>
> PS
>
> It's OK if the function has to depend on eg a graphics context etc.
> (I tried writing a function so that it extracts the glyphs, using
> NSTextStorage, NSLayoutManager and the AppleColorEmoji font, but it says
> that "‍‍‍‍♀️" contains 18(!) glyphs, whereas eg "café" contains
> 4 as expected.)
>
> If the emojis of the third example doesn't look like they should in this
> mail, here is another way to write the exact same example using only simple
> text:
>
> let inputOfThirdExample = "\u{1F468}\u{200D}\u{1F469}\u{
> 200D}\u{1F467}\u{200D}\u{1F466}\u{1F477}\u{1F3FE}\u{200D}\u{2640}\u{FE0F}"
>
> let result = f(inputOfThirdExample)
>
> let expectedResult = ["\u{1F468}\u{200D}\u{1F469}\
> u{200D}\u{1F467}\u{200D}\u{1F466}", "\u{1F477}\u{1F3FE}\u{200D}\u{
> 2640}\u{FE0F}"]
>
> print(result.elementsEqual(result)) // Should print true
>
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Splitting a string into "natural/visual character" components?

[Jens Persson via swift-users]

I want a function f such that:

f("abc") == ["a", "b", "c"]

f("café") == ["c", "a", "f", "é"]

f("‍‍‍‍♀️") == ["‍‍‍", "‍♀️"]

I'm not sure if the last example renders correctly by mail for everyone but
the input String contains these _two_ "natural/visual characters":
(1) A family emoji
(2) a construction worker (woman, with skin tone modifier) emoji.
and the result is an Array of two strings (one for each emoji).

The first two examples are easy, the third example is the tricky one.

Is there a (practical) way to do this (in Swift 3)?

/Jens



PS

It's OK if the function has to depend on eg a graphics context etc.
(I tried writing a function so that it extracts the glyphs, using
NSTextStorage, NSLayoutManager and the AppleColorEmoji font, but it says
that "‍‍‍‍♀️" contains 18(!) glyphs, whereas eg "café" contains
4 as expected.)

If the emojis of the third example doesn't look like they should in this
mail, here is another way to write the exact same example using only simple
text:

let inputOfThirdExample =
"\u{1F468}\u{200D}\u{1F469}\u{200D}\u{1F467}\u{200D}\u{1F466}\u{1F477}\u{1F3FE}\u{200D}\u{2640}\u{FE0F}"

let result = f(inputOfThirdExample)

let expectedResult =
["\u{1F468}\u{200D}\u{1F469}\u{200D}\u{1F467}\u{200D}\u{1F466}",
"\u{1F477}\u{1F3FE}\u{200D}\u{2640}\u{FE0F}"]

print(result.elementsEqual(result)) // Should print true
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users