[swift-users] Cancelling an SPM build cleanly

[Geordie J via swift-users]

I was just reminded of this issue by another thread (thanks Daniel Dunbar for 
https://github.com/apple/swift-llbuild/pull/196 
!)

Is it possible to cancel an SPM build cleanly? If I run swift build and then 
press Ctrl-C halfway through I end up in a weird broken state that requires a 
swift package clean before anything works again. Maybe because SPM thinks it’s 
still building the last job?

I ask because sometimes I start a build, realise I actually wanted to make one 
more change and then press start again. This works in Xcode and breaks in SPM.

Thanks,
Geordie


signature.asc
Description: Message signed with OpenPGP
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] SwiftProtobuf unable to link on Ubuntu

[Geordie J via swift-users]

Hi Edward,

> Am 14.10.2017 um 22:35 schrieb Edward Connell :
> 
> Hi Geordie,
> That is actually a capital "I" eye for import
> This font make an eye and elle look the same. This is the build line I am 
> trying to use.

My apologies.

> 
> swift build -Xswiftc -I/home/ed/swift-protobuf/.build/release -Xlinker 
> -L/home/ed/swift-protobuf/.build/release

Have you considered using Swift Package Manager to add protobuf as a project 
dependency? Then you wouldn’t have to mess around with command line arguments 
at all. I haven’t used protobuf yet so can’t help with specifics.

Cheers,
Geordie

> 
> On Sat, Oct 14, 2017 at 1:00 PM, Geordie J  > wrote:
> Hi
> 
>> Am 14.10.2017 um 21:55 schrieb Edward Connell via swift-users 
>> >:
>> 
>> Has anyone used the SwiftProtobuf module on Linux?
>> https://github.com/apple/swift-protobuf 
>> 
>> 
>> I am able to successfully generate swift classes from my proto file.
>> However when building, the code compiles but I get a ton of undefined link 
>> references.
>> 
>> I included -Xswiftc -I/home/ed/swift-protobuf/.build/release so the module 
>> is found, but still….
> 
> This should be "-Xlinker” rather than “-Xswiftc”, and also “-l” is for 
> specifying system library names (e.g. "-latomic”). I’m pretty new to this but 
> I think the correct flag is “-L”.
> So in the past I have used “-Xlinker -L/path/to/libs”, but I’ve recently read 
> you can actually leave off “-Xlinker” and just have the “-L” bit.
> 
> Hope that helps.
> 
> - Geordie
> 
>> 
>> 
>> /home/ed/Documents/prototest/Sources/DataModel.pb.swift:31: error: undefined 
>> reference to '_T013SwiftProtobuf14UnknownStorageVACycfC'
>> /home/ed/Documents/prototest/Sources/DataModel.pb.swift:31: error: undefined 
>> reference to '_T013SwiftProtobuf14UnknownStorageVACycfC'
>> /home/ed/Documents/prototest/Sources/DataModel.pb.swift:64: error: undefined 
>> reference to 
>> '_T013SwiftProtobuf14UnknownStorageV8traverseyxz7visitor_tKAA7VisitorRzlF'
>> /home/ed/Documents/prototest/Sources/DataModel.pb.swift:0: error: undefined 
>> reference to '_T013SwiftProtobuf7MessagePAAE13isInitializedSbfg'
>> 
>> etc...
>> 
>> Does anyone have a simple working example on Ubuntu?
>> 
>> Ubuntu 16.04
>> Swift 4.0 release
>> 
>> Thanks, Ed
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] SwiftProtobuf unable to link on Ubuntu

[Geordie J via swift-users]

Hi

> Am 14.10.2017 um 21:55 schrieb Edward Connell via swift-users 
> :
> 
> Has anyone used the SwiftProtobuf module on Linux?
> https://github.com/apple/swift-protobuf 
> 
> 
> I am able to successfully generate swift classes from my proto file.
> However when building, the code compiles but I get a ton of undefined link 
> references.
> 
> I included -Xswiftc -I/home/ed/swift-protobuf/.build/release so the module is 
> found, but still….

This should be "-Xlinker” rather than “-Xswiftc”, and also “-l” is for 
specifying system library names (e.g. "-latomic”). I’m pretty new to this but I 
think the correct flag is “-L”.
So in the past I have used “-Xlinker -L/path/to/libs”, but I’ve recently read 
you can actually leave off “-Xlinker” and just have the “-L” bit.

Hope that helps.

- Geordie

> 
> 
> /home/ed/Documents/prototest/Sources/DataModel.pb.swift:31: error: undefined 
> reference to '_T013SwiftProtobuf14UnknownStorageVACycfC'
> /home/ed/Documents/prototest/Sources/DataModel.pb.swift:31: error: undefined 
> reference to '_T013SwiftProtobuf14UnknownStorageVACycfC'
> /home/ed/Documents/prototest/Sources/DataModel.pb.swift:64: error: undefined 
> reference to 
> '_T013SwiftProtobuf14UnknownStorageV8traverseyxz7visitor_tKAA7VisitorRzlF'
> /home/ed/Documents/prototest/Sources/DataModel.pb.swift:0: error: undefined 
> reference to '_T013SwiftProtobuf7MessagePAAE13isInitializedSbfg'
> 
> etc...
> 
> Does anyone have a simple working example on Ubuntu?
> 
> Ubuntu 16.04
> Swift 4.0 release
> 
> Thanks, Ed
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users



signature.asc
Description: Message signed with OpenPGP
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] [swift-build-dev] SwiftPM manual dependency management

[Geordie J via swift-users]

Thanks for the update on this one. Judging by the thread, it looks like it’ll 
need to be handled internally by Apple. Also, I have no idea how to reply to 
the existing post without breaking the internet so I’m going to just wait 
patiently instead..

> Am 23.07.2017 um 01:11 schrieb David Sweeris  >:
> 
> 
> On Jul 22, 2017, at 16:09, David Sweeris via swift-build-dev 
> > wrote:
>> 
>> Within the past day or so, someone on evolution rezzed Ted's announcement 
>> thread on the matter.
> 
> Whoops, I was wrong, it's a new thread called "Setting expectations on when 
> we move to Discourse"

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

Re: [swift-users] [swift-build-dev] SwiftPM manual dependency management

[Geordie J via swift-users]

> Am 22.07.2017 um 19:46 schrieb David Sweeris :
> 
> 
> 
> Sent from my iPhone
> 
>> On Jul 22, 2017, at 05:16, Geordie Jay via swift-build-dev 
>>  wrote:
>> 
>> How can I get involved in the evolution of this? The evolutions are always 
>> uneditable uncommentable markdown files on a repo somewhere and the mailing 
>> lists are in my practical experience inpentrible especially for entries you 
>> weren't subscribed to the list for, or were "only" subscribed to the digest 
>> for. I wish they were on google docs or a hackpad equivalent. Is there 
>> "officially recognised" discussion on the SwiftPM dev slack channel 
>> regarding evolution topics?
> 
> Yeah, I'm not a mailing list fan, either (at least for long or active 
> threads), and you have nicely summarized the reasons we decided to move to a 
> discourse server. It's just that it hasn't happened yet.
> 
> To answer your question more directly, you can of course discuss things on 
> slack, twitter, in-person, off-list email, or in any other way, but AFAIK of 
> you want your conversation to be "on-record", you need to have it on-list. 
> Until we move to discourse, of course.
> 
> I realize that doesn't actually solve the problem, I hope it at least gives 
> you some moral support.
> 
> - Dave Sweeris (who speaks only for himself and shouldn't be taken as 
> official source of information on this matter)

This is morale-boosting news! Was this discussed somewhere public? I can hardly 
wait, and would be willing to put some of my spare time into facilitating the 
move if that’s at all interesting to those making the decisions on this one.

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

Re: [swift-users] SwiftPM manual dependency management

[Geordie J via swift-users]

Hi Ankit,

> Am 21.07.2017 um 15:32 schrieb Ankit Aggarwal via swift-users 
> <swift-users@swift.org>:
> 
> +swift-build-dev
> 
>> On 21-Jul-2017, at 6:09 PM, Geordie J <geo...@gmail.com 
>> <mailto:geo...@gmail.com>> wrote:
>> 
>> Hi Ankit, thanks for your reply.
>> 
>>> Am 21.07.2017 um 07:33 schrieb Ankit Aggarwal via swift-users 
>>> <swift-users@swift.org <mailto:swift-users@swift.org>>:
>>> 
>>> 
>>> 
>>> On Thu, Jul 20, 2017 at 10:34 PM, Geordie J via swift-users 
>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>> Hi all,
>>> 
>>> My team and I are trying to use SwiftPM to develop a relatively complex app 
>>> with multiple dependencies, all of which are being developed locally and in 
>>> parallel. The reason for this is compatibility with an existing 
>>> module/import structure used by our iOS app. Maybe I’m doing something very 
>>> wrong but my experience so far (2 months in) is that this is extremely 
>>> difficult with SwiftPM.
>>> 
>>> What I’d love to be able to do is to just run `git add submodule 
>>> http://blah.com/mysubmodule.git` <http://blah.com/mysubmodule.git%60> in 
>>> the Packages subdirectory and SwiftPM would just let me manage dependencies 
>>> from there myself.
>>> 
>>> I was excited to see that SwiftPM 4 has a "Top of Tree" development option 
>>> for this purpose. So far my experience with this has not been good. Firstly 
>>> because SwiftPM still unnecessarily tries to clone my repos itself (some of 
>>> which are huge), and secondly because this creates an absolute path 
>>> dependency in `.build/dependencies-state.json`, meaning this setup isn’t 
>>> sharable within our dev team.
>>> 
>>> Attempting this with "local" git urls adds an almost absurd level of 
>>> complexity, having to tag each commit for SwiftPM to build. The fact that 
>>> we'd need to make a commit to test whether the project even builds is 
>>> insane enough as is, let alone the tagging and trying to tell the base 
>>> project to use a newer minor version etc etc.
>>> 
>>> Adding multiple subtargets is also not an option because the dependencies 
>>> (as dynamic libraries) really are shared between multiple 
>>> targets/sub-dependencies, which SwiftPM seems to deal with quite well.
>>> 
>>> tldr; *Please* let us manage dependencies ourselves. It’d be so easy if 
>>> Package.swift had an option along the lines of .Package.local(named: "XYZ") 
>>> that it then looked for in ./Packages/XYZ. Again, maybe I’m overlooking 
>>> something but this seems like an obvious and vital option to have. It’d 
>>> also simplify the introductory SwiftPM docs significantly.
>>> 
>>> Is anyone else having this issue? Would this change really be as simple and 
>>> painless as it sounds? I would be prepared to make a pull request along 
>>> these lines.
>>> 
>>> I think you're not really using the Top of Tree feature. You need to add 
>>> each dependency using its canonical URL, hosted at some server like github. 
>>> After adding the dependencies, you can use edit feature to put a dependency 
>>> in Top of Tree mode. To do so, run:
>>> 
>>> $ swift package edit  --path 
>>> ../path/to/self/managed/checkout/of/the/package
>> 
>> Yes, this is what I tried this week. I’m pretty sure this is not a case of 
>> misunderstanding the feature or the docs.
>> 
> 
> Ah, cool!
> 
>>> 
>>> The package manager will then stop using the cloned repository and use the 
>>> checkout present at that path (regardless of the state it is in).
>> 
>> Yes, but then I have – per dependency – two checkouts of a potentially huge 
>> repository. Why force everyone on the dev team to clone a huge repo twice, 
>> only to *never* use one of the clones.
> 
> Sure, you could end up with clones but that is only an implementation detail. 
> SwiftPM can become smart enough and remove a clone that is not being used.
> 
>> Also, SwiftPM breaks when —path points at Packages/PackageName, which is 
>> exactly where I’d expect the package to be, not in some arbitrary external 
>> path (+ some kind of internal checkout cache that will never be used) as 
>> well.
> 
> If --path Packages/PackageName doesn't work, that is a bug! Do you mind 
> filing a JIRA at bugs.swift.org <http://bugs.swift.org/>? 

SwiftPM

Re: [swift-users] SwiftPM manual dependency management

[Geordie J via swift-users]

Hi Ankit, thanks for your reply.

> Am 21.07.2017 um 07:33 schrieb Ankit Aggarwal via swift-users 
> <swift-users@swift.org>:
> 
> 
> 
> On Thu, Jul 20, 2017 at 10:34 PM, Geordie J via swift-users 
> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
> Hi all,
> 
> My team and I are trying to use SwiftPM to develop a relatively complex app 
> with multiple dependencies, all of which are being developed locally and in 
> parallel. The reason for this is compatibility with an existing module/import 
> structure used by our iOS app. Maybe I’m doing something very wrong but my 
> experience so far (2 months in) is that this is extremely difficult with 
> SwiftPM.
> 
> What I’d love to be able to do is to just run `git add submodule 
> http://blah.com/mysubmodule.git` <http://blah.com/mysubmodule.git%60> in the 
> Packages subdirectory and SwiftPM would just let me manage dependencies from 
> there myself.
> 
> I was excited to see that SwiftPM 4 has a "Top of Tree" development option 
> for this purpose. So far my experience with this has not been good. Firstly 
> because SwiftPM still unnecessarily tries to clone my repos itself (some of 
> which are huge), and secondly because this creates an absolute path 
> dependency in `.build/dependencies-state.json`, meaning this setup isn’t 
> sharable within our dev team.
> 
> Attempting this with "local" git urls adds an almost absurd level of 
> complexity, having to tag each commit for SwiftPM to build. The fact that 
> we'd need to make a commit to test whether the project even builds is insane 
> enough as is, let alone the tagging and trying to tell the base project to 
> use a newer minor version etc etc.
> 
> Adding multiple subtargets is also not an option because the dependencies (as 
> dynamic libraries) really are shared between multiple 
> targets/sub-dependencies, which SwiftPM seems to deal with quite well.
> 
> tldr; *Please* let us manage dependencies ourselves. It’d be so easy if 
> Package.swift had an option along the lines of .Package.local(named: "XYZ") 
> that it then looked for in ./Packages/XYZ. Again, maybe I’m overlooking 
> something but this seems like an obvious and vital option to have. It’d also 
> simplify the introductory SwiftPM docs significantly.
> 
> Is anyone else having this issue? Would this change really be as simple and 
> painless as it sounds? I would be prepared to make a pull request along these 
> lines.
> 
> I think you're not really using the Top of Tree feature. You need to add each 
> dependency using its canonical URL, hosted at some server like github. After 
> adding the dependencies, you can use edit feature to put a dependency in Top 
> of Tree mode. To do so, run:
> 
> $ swift package edit  --path 
> ../path/to/self/managed/checkout/of/the/package

Yes, this is what I tried this week. I’m pretty sure this is not a case of 
misunderstanding the feature or the docs.

> 
> The package manager will then stop using the cloned repository and use the 
> checkout present at that path (regardless of the state it is in).

Yes, but then I have – per dependency – two checkouts of a potentially huge 
repository. Why force everyone on the dev team to clone a huge repo twice, only 
to *never* use one of the clones. Also, SwiftPM breaks when —path points at 
Packages/PackageName, which is exactly where I’d expect the package to be, not 
in some arbitrary external path (+ some kind of internal checkout cache that 
will never be used) as well.

I haven’t tried to test this recently because it’s a slow process but I have 
the impression the deps could be even be cloned more than twice, depending on 
how cleverly SwiftPM realises that multiple Packages have the same dependency.

Also, this makes managing interdependent state of development amongst 
dependencies more difficult than needed. How do we guarantee that devs are on 
the same commit when using top of tree development? Tagging and managing 
version numbers etc for day-to-day development is emphatically not an option 
for us. Since SwiftPM packages only work from a git context anyway, why not 
allow use of git’s established pattern of dealing with this, namely submodules?

> Sharing this setup is not automatic, but simple. Each user just needs to run 
> the above command once per dependency.

We have about 10 dependencies, all of which will always be in this state. This 
seems like a lot of overhead and room for user error, plus it’s a huge 
workaround for something that could be very simple.

> Also, you only need to do this if you're actively working on a dependency.

The point is that we will always be working on the dependencies. This is the 
core of what we’re doing, not a short aside. This is what makes me think we

[swift-users] SwiftPM manual dependency management

[Geordie J via swift-users]

Hi all,

My team and I are trying to use SwiftPM to develop a relatively complex app 
with multiple dependencies, all of which are being developed locally and in 
parallel. The reason for this is compatibility with an existing module/import 
structure used by our iOS app. Maybe I’m doing something very wrong but my 
experience so far (2 months in) is that this is extremely difficult with 
SwiftPM.

What I’d love to be able to do is to just run `git add submodule 
http://blah.com/mysubmodule.git`  in the 
Packages subdirectory and SwiftPM would just let me manage dependencies from 
there myself.

I was excited to see that SwiftPM 4 has a "Top of Tree" development option for 
this purpose. So far my experience with this has not been good. Firstly because 
SwiftPM still unnecessarily tries to clone my repos itself (some of which are 
huge), and secondly because this creates an absolute path dependency in 
`.build/dependencies-state.json`, meaning this setup isn’t sharable within our 
dev team.

Attempting this with "local" git urls adds an almost absurd level of 
complexity, having to tag each commit for SwiftPM to build. The fact that we'd 
need to make a commit to test whether the project even builds is insane enough 
as is, let alone the tagging and trying to tell the base project to use a newer 
minor version etc etc.

Adding multiple subtargets is also not an option because the dependencies (as 
dynamic libraries) really are shared between multiple targets/sub-dependencies, 
which SwiftPM seems to deal with quite well.

tldr; *Please* let us manage dependencies ourselves. It’d be so easy if 
Package.swift had an option along the lines of .Package.local(named: "XYZ") 
that it then looked for in ./Packages/XYZ. Again, maybe I’m overlooking 
something but this seems like an obvious and vital option to have. It’d also 
simplify the introductory SwiftPM docs significantly.

Is anyone else having this issue? Would this change really be as simple and 
painless as it sounds? I would be prepared to make a pull request along these 
lines.

Best Regards,
Geordie


PS. In SwiftPM 3 we had been using a hack that worked great: by filling in the 
dependencies' "basedOn" key in `workspace-state.json`, SwiftPM just left us 
alone.. We were able to commit `workspace-state.json` into our base project’s 
git repo and the rest Just Worked™. Now with the absolute paths being checked 
for this doesn’t seem to be an option.___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] How to write better Swift

[Geordie J via swift-users]

Would "didSet" on a normal variable work for you?

var status: Int {
  didSet { doSomething() }
}

Geordie


> Am 10.07.2017 um 17:34 schrieb Gerriet M. Denkmann via swift-users 
> :
> 
> This works (Xcode Version 8.3.2 (8E2002)):
> 
> class SomeClass
> {
>   private var privateStatus: Int  
> 
>   var status: Int
>   {
>   get{ return privateStatus }
>   set(new)
>   {
>   if new == privateStatus {return}
>   
>   … do something here …
> 
>   privateStatus = new
>   }
>   }
> }
> 
> But is this “privateStatus” really necessary?
> If not, how can it be avoided?
> 
> Gerriet.
> 
> ___
> 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] Compile time exceeded. Anything wrong?

[Geordie J via swift-users]

Interesting, I guess it’s anything with multiple possible function overloads 
then! It looks pretty trivial though to figure out the two components before 
trying to figure out which function, which should lead to the result in a 
reasonable time. There must be something else going on. Good work on filing the 
bug! Hope this gets fixed soon.

Geordie

> Am 06.06.2017 um 22:49 schrieb Jens Persson :
> 
> You're right that it's not functionally eq, sorry about that.
> I filed https://bugs.swift.org/browse/SR-5093 
>  containing a reduced example program 
> to demonstrate the issue..
> Haven't tested it with anything later than the 2017-06-02 snapshot.
> But it shows that it's not just max that is the problem.
> /Jens
> 
> On Tue, Jun 6, 2017 at 4:51 AM, Geordie Jay  > wrote:
> I doubt it'll be "fixed" in the next release (which came out less than 24 
> hours ago), but I gather type checker speed optimisations and fixing crashes 
> are ongoing goals of the compiler team. With no guarantees or expectations, 
> you may find your code compiles in an acceptable time with Swift 4 (Xcode 9).
> 
> Cheers,
> Geordie
> 
> On Tue 6. Jun 2017 at 12:29, > 
> wrote:
> thanks,  guys!  dp array should be var, not let, but the compile run too 
> slow. It indeed a bug.  Optimizing  the code for the compiling time is really 
> a headache for coders.  I am using the Xcode 8.1. Hoping it can be fixed in 
> next release.
> 
> 
> best wishes for you 
> 
> 2017-06-06 8:57 GMT+08:00 Geordie J  >:
> 
>> Am 06.06.2017 um 09:02 schrieb Jens Persson via swift-users 
>> >:
>> 
>> When compiling that from the command line, I get the following (after about 
>> 6 seconds):
>> 
>> test.swift:7:18: error: cannot assign through subscript: 'dp' is a 'let' 
>> constant
>> dp[0][0] = 0
>> ~~   ^
>> /.../
>> 
>> After fixing that (changing let dp to var dp), it will compile successfully, 
>> still taking a very long time though. This usually means that some 
>> expression(s) in the code happen to be a bit hard on the type checker (in 
>> its current state).
>> I tried the latest dev snapshot and it is a bit faster, perhaps 3 s instead 
>> of 6.
>> 
>> Anyway, here is a logically equivalent rewrite which will compile faster:
>> 
>> class Solution {
>> func rob(nums: [Int]) -> Int {
>> guard nums.count > 0 else { return 0 }
>> var dp = Array.init(repeating: Array.init(repeating: 0, count: 
>> nums.count),
>> count: 2)
>> dp[0][0] = 0
>> dp[0][1] = nums[0]
>> for i in 1 ..< nums.count {
>> let dp_iMinus1_0 = dp[i - 1][0] 
>> let dp_iMinus1_1 = dp[i - 1][1] 
>> dp[i][0] = max(dp_iMinus1_0, dp_iMinus1_1)
>> dp[i][1] = dp_iMinus1_0 + nums[i]
> 
> Just a nitpick: this isn’t functionally equivalent to the original code 
> (dp[i][1] = dp[i][0] + nums[i]), because dp[i][0] might have actually changed 
> on the previous line. But you can return this line to the original version 
> without any effect on the compile time (less than 250ms on my machine).
> 
> I think the compile time issue is that max() is a generic function that takes 
> any Comparable, so the type checker seems to go berserk trying to ensure the 
> term is satisfiable.
> 
> If you create a non-generic replacement for max in the same file:
> 
> private func myMax(_ x1: Int, _ x2: Int) -> Int {
> return (x1 >= x2) ? x1 : x2
> }
> 
> … and replace the assignment to max(dp[i - 1][0], ……) in the for loop with 
> myMax(dp[i - 1][0], ….)
> 
> The compile time will be just as fast as the one that swaps out the internal 
> elements (on my machine it’s actually about 10% faster with the non-generic 
> max).
> 
> Regards,
> Geordie
> 
>> }
>> return 0
>> }
>> }
>> 
>> 
>> 
>> 
>> 
>> On Mon, Jun 5, 2017 at 2:32 PM, Hbucius Smith via swift-users 
>> > wrote:
>> Hi Swift-Users,
>> 
>> when I compiled the code, Xcode cannot stop, I do not know why. It is 
>> very strange. Can anyone help ? Here is the code. I am using Xcode 8.1
>> 
>> class Solution {
>> 
>> func rob(nums: [Int]) -> Int {
>> 
>> guard nums.count > 0 else { return 0 }
>> 
>> let dp = Array.init(repeating: Array.init(repeating: 0, count: 
>> nums.count),
>> 
>> count: 2)
>> 
>> dp[0][0] = 0
>> 
>> dp[0][1] = nums[0]
>> 
>> for i in 1 ..< nums.count {
>> 
>> dp[i][0] = max(dp[i - 1][0], dp[i - 1][1])
>> 
>> dp[i][1] = dp[i - 1][0] + nums[i]
>> 
>> }
>> 
>> return 0
>> 
>> }
>> 
>> }
>> 
>> 
>> 
>> 
>> best wishes for you 
>> 
>> 

Re: [swift-users] Calling default implementation of protocol methods as selectors

[Geordie J via swift-users]

In fact, this would be even better (avoids unnecessary implicitly unwrapped 
optionals):

class ClosureGestureRecognizer {
fileprivate var recognizer: GestureRecognizer
private var onAction: ((GestureRecognizer) -> Void)

init(onAction: @escaping ((GestureRecognizer) -> Void)) {
self.recognizer = GestureRecognizer()
self.onAction = onAction

self.recognizer.addTarget(self, action: #selector(actionHandler))
}

@objc private func actionHandler() {
onAction(recognizer)
}
}

extension UIView {
func addGestureRecognizer(_ gestureRecognizer: 
ClosureGestureRecognizer) {
self.addGestureRecognizer(gestureRecognizer.recognizer)
}
}

Depending on your use-case, it’d be no problem to make onAction a non-private 
(externally settable) optional closure—in case you want to avoid having to set 
it on init of ClosureGestureRecognizer.

Cheers,
Geordie


> Am 04.06.2017 um 23:09 schrieb Geordie J :
> 
> To get around the issue of using self on init, but also that of multiple 
> recogniser types, try this:
> 
> class ClosureGestureRecognizer {
> // These are initially nil and set on init to their desired values.
> // This gets around the issue of using self in init.
> // `private` means they can't ever actually be nil:
> private var recognizer: RecognizerType!
> private var onAction: ((RecognizerType) -> Void)!
> 
> init(callback: @escaping ((RecognizerType) -> Void)) {
> recognizer = RecognizerType(target: self, action: 
> #selector(actionHandler))
> self.onAction = callback
> }
> 
> @objc private func actionHandler() {
> onAction(recognizer)
> }
> }
> 
> let recognizer = ClosureGestureRecognizer(callback: { 
> panGestureRecognizer in
> print("Panned, translation:", panGestureRecognizer.translation(in: nil))
> })
> 
> Regards,
> Geordie
> 
> 
>> Am 04.06.2017 um 21:55 schrieb Zhao Xin > >:
>> 
>> Will this work?
>> 
>> class TapGestureRecognizer: UITapGestureRecognizer {
>> var onTap: (() -> Void)?
>> init(onTap: (() -> Void)?) {
>> self.onTap = onTap
>> super.init(target: nil, action: nil)
>> self.removeTarget(nil, action: nil)
>> self.addTarget(self, action: #selector(internalTapHandler))
>> print(self)
>> }
>> 
>> @objc private func internalTapHandler() {
>> onTap?()
>> }
>> }
>> 
>> Zhao Xin
>> 
>> On Sun, Jun 4, 2017 at 5:24 PM, Nate Birkholz > > wrote:
>> Also, note that I tried the following:
>> 
>> class BlockTapGestureRecognizer: UIGestureRecognizer {
>> var onTap: (() -> Void)?
>> init(onTap: (() -> Void)?) {
>> self.onTap = onTap
>> super.init(target: nil, action: nil)
>> self.addTarget(self, action: #selector(internalTapHandler))
>> print(self)
>> }
>> 
>> @objc private func internalTapHandler() {
>> onTap?()
>> }
>> }
>> 
>> And the object prints looking okay:
>> 
>> > UIGestureRecognizer; state = Possible; view = ; target= 
>> <(action=internalTapHandler, target=> 0x1701998b0>)>>
>> 
>> But it doesn't in practice work. The documentation for the (target: action:) 
>> initializer states:
>> 
>> target: An object that is the recipient of action messages sent by the 
>> receiver when it recognizes a gesture. nil is not a valid value.
>> action: A selector that identifies the method implemented by the target to 
>> handle the gesture recognized by the receiver. The action selector must 
>> conform to the signature described in the class overview. NULL is not a 
>> valid value.
>> 
>> So something is going on inside there when the nil values are passed to the 
>> recognizer. As the documentation states, nil is not a valid value and it 
>> must cause troubles.
>> 
>> Or I did something wrong?
>> 
>> 
>> 
>> On Sun, Jun 4, 2017 at 1:55 AM, Nate Birkholz > > wrote:
>> Ah, I didn't read the rest of the thread. As Zhao Xin notes, you cannot call 
>> super.init(target: self, action: #selector()), and you cannot call 
>> super.init() in a subclass init or convenience init, it *has* to be the 
>> designated init method init(target:action:). That's too bad, closure-based 
>> gesture recognizers would be snazzy and swifty and I'd love to see them as 
>> part of UIKit. 
>> 
>> I could write my own custom implementations of subclassed 
>> UIKit.UIGestureRecognizerSubclass(es), but as the screens in question have 
>> tap, swipe up, swipe down, and swipe right gesture recognizers, I feel its 
>> overkill to write all that to avoid repeating ~10 lines of code.
>> 
>> On Sun, Jun 4, 2017 at 1:21 AM, Nate Birkholz > > wrote:
>> I briefly considered something like this but didn't explore it. Elegant.
>> 
>> Sent from my iPhone, please excuse brevity and 

Re: [swift-users] Calling default implementation of protocol methods as selectors

[Geordie J via swift-users]

To get around the issue of using self on init, but also that of multiple 
recogniser types, try this:

class ClosureGestureRecognizer {
// These are initially nil and set on init to their desired values.
// This gets around the issue of using self in init.
// `private` means they can't ever actually be nil:
private var recognizer: RecognizerType!
private var onAction: ((RecognizerType) -> Void)!

init(callback: @escaping ((RecognizerType) -> Void)) {
recognizer = RecognizerType(target: self, action: 
#selector(actionHandler))
self.onAction = callback
}

@objc private func actionHandler() {
onAction(recognizer)
}
}

let recognizer = ClosureGestureRecognizer(callback: { 
panGestureRecognizer in
print("Panned, translation:", panGestureRecognizer.translation(in: nil))
})

Regards,
Geordie


> Am 04.06.2017 um 21:55 schrieb Zhao Xin :
> 
> Will this work?
> 
> class TapGestureRecognizer: UITapGestureRecognizer {
> var onTap: (() -> Void)?
> init(onTap: (() -> Void)?) {
> self.onTap = onTap
> super.init(target: nil, action: nil)
> self.removeTarget(nil, action: nil)
> self.addTarget(self, action: #selector(internalTapHandler))
> print(self)
> }
> 
> @objc private func internalTapHandler() {
> onTap?()
> }
> }
> 
> Zhao Xin
> 
> On Sun, Jun 4, 2017 at 5:24 PM, Nate Birkholz  > wrote:
> Also, note that I tried the following:
> 
> class BlockTapGestureRecognizer: UIGestureRecognizer {
> var onTap: (() -> Void)?
> init(onTap: (() -> Void)?) {
> self.onTap = onTap
> super.init(target: nil, action: nil)
> self.addTarget(self, action: #selector(internalTapHandler))
> print(self)
> }
> 
> @objc private func internalTapHandler() {
> onTap?()
> }
> }
> 
> And the object prints looking okay:
> 
>  UIGestureRecognizer; state = Possible; view = ; target= 
> <(action=internalTapHandler, target= 0x1701998b0>)>>
> 
> But it doesn't in practice work. The documentation for the (target: action:) 
> initializer states:
> 
> target: An object that is the recipient of action messages sent by the 
> receiver when it recognizes a gesture. nil is not a valid value.
> action: A selector that identifies the method implemented by the target to 
> handle the gesture recognized by the receiver. The action selector must 
> conform to the signature described in the class overview. NULL is not a valid 
> value.
> 
> So something is going on inside there when the nil values are passed to the 
> recognizer. As the documentation states, nil is not a valid value and it must 
> cause troubles.
> 
> Or I did something wrong?
> 
> 
> 
> On Sun, Jun 4, 2017 at 1:55 AM, Nate Birkholz  > wrote:
> Ah, I didn't read the rest of the thread. As Zhao Xin notes, you cannot call 
> super.init(target: self, action: #selector()), and you cannot call 
> super.init() in a subclass init or convenience init, it *has* to be the 
> designated init method init(target:action:). That's too bad, closure-based 
> gesture recognizers would be snazzy and swifty and I'd love to see them as 
> part of UIKit. 
> 
> I could write my own custom implementations of subclassed 
> UIKit.UIGestureRecognizerSubclass(es), but as the screens in question have 
> tap, swipe up, swipe down, and swipe right gesture recognizers, I feel its 
> overkill to write all that to avoid repeating ~10 lines of code.
> 
> On Sun, Jun 4, 2017 at 1:21 AM, Nate Birkholz  > wrote:
> I briefly considered something like this but didn't explore it. Elegant.
> 
> Sent from my iPhone, please excuse brevity and errors
> 
> On Jun 3, 2017, at 9:38 PM, Geordie Jay  > wrote:
> 
>> I am dealing with a variant of this on Android right now. I have just 
>> subclassed e.g. UITapGestureRecognizer to perform the 2nd variant above and 
>> externally accept a closure as its argument. I'm writing this on my phone so 
>> forgive any syntax errors or accidental omissions:
>> 
>> class TapGestureRecognizer: UITapGestureRecognizer {
>> var onTap: (() -> Void)?
>> init(onTap: (() -> Void)?) {
>> self.onTap = onTap
>> super.init(target: self, action: #selector(internalTapHandler))
>> }
>> 
>> @objc private func internalTapHandler() {
>> onTap?()
>> }
>> }
>> 
>> class Baz: Foo {
>> init() {
>> let tapRecognizer = TapGestureRecognizer(onTap: self.bar)
>> }
>> }
>> 
>> 
>> Cheers,
>> Geordie
>> On Sat 3. Jun 2017 at 16:53, Nate Birkholz via swift-users 
>> > wrote:
>> Thanks, the second had occurred to me, but felt a little too much like in 
>> practice it would make the code harder to understand.
>> 
>> On Fri, Jun 2, 2017 at 9:58 PM, Zhao Xin > 

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 <geo...@gmail.com>:
> 
> 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 <rm...@latencyzero.com <mailto:rm...@latencyzero.com>> 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 <mailto:swift-users@swift.org>> wrote:
> >
> >
> >> On May 3, 2017, at 4:10 PM, Geordie J via swift-users 
> >> <swift-users@swift.org <mailto: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 
> > <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
> >  
> > <https://github.com/apple/swift-clang/blob/stable/lib/APINotes/APINotesYAMLCompiler.cpp>
> >
> >   - Doug
> >
> > ___
> > swift-users mailing list
> > swift-users@swift.org <mailto:swift-users@swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-users 
> > <https://lists.swift.org/mailman/listinfo/swift-users>
> 
> 
> --
> Rick Mann
> rm...@latencyzero.com <mailto:rm...@latencyzero.com>
> 
> 

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

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

[Geordie J via swift-users]

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.

Thanks in advance,
Geordie

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

[swift-users] Using .gyb outside of the stdlib

[Geordie J via swift-users]

Hi again, another question:

Is it possible to use .gyb files to automatically generate repetitive code 
outside of the stdlib? Preferably in a SwiftPM package? Here’s an example of 
what I’ve been using it for:

https://github.com/SwiftAndroid/swift-jni/blob/master/JNIFields.swift.gyb 


Thanks,
Geordie___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users