|
http://www.jessesquires.com/apples-to-apples-part-two/ drat, ladies. Things are getting Swift!
|
# ? Aug 6, 2014 23:29 |
|
|
# ? May 15, 2024 03:32 |
|
ultramiraculous posted:http://www.jessesquires.com/apples-to-apples-part-two/ No poo poo it's faster all he's doing is showing that objc_msgSend is a bottleneck Dump them to (C) arrays and use qsort on the values and/or cache the comparator and it'd be much faster. That said swift does it by default.
|
# ? Aug 9, 2014 16:00 |
|
It's an interesting question. Objective-C embeds C; any sort of benchmark showing Objective-C to be slow can be met with the objection, "Well, if the performance really mattered here, I would just drop down to C." That's a reasonable response inasmuch as it's a real strength of Objective-C that using C techniques in any particular method implementation is so painless. On the other hand, that means you're no longer really comparing against Objective-C, because you're (locally) losing basically everything that Objective-C gives you; it also implies that you're losing a lot of performance in the long tail of places that you will never plausibly get around to hand-optimizing. On the other other hand, that performance buys a lot of dynamic flexibility that this workload could, but does not, take advantage of. Most language benchmarks tell a complex story like this. For what it's worth, we internally wrote up cute benchmarks like this years ago, but AFAIK we've never bragged about them, mostly because we felt that it requires too much explanation. On one final note, I want to point out that the performance difference is not really about the direct overhead of objc_msgSend; you could duplicate most of it by just taking every message send and making it a call to a function implemented in a different file. It's about boxing and the abstraction penalty of making an opaque call instead of an inlineable one.
|
# ? Aug 9, 2014 18:17 |
|
code:
swiftc posted:{a=5, b=1, c=1, d=1, e=1} Wat edit: this works just fine code:
code:
rdar://17973350 and rdar://17973340 Simulated fucked around with this message at 05:36 on Aug 11, 2014 |
# ? Aug 11, 2014 05:22 |
|
Has anyone found a better solution to sharing Swift and Obj-C interop between build Targets?: Given that Swift -> Obj-C headers are named after the target that generates them of the form: "TargetA-Swift.h"... And I have Swift and Obj-C files I want to share between targets A and B Foo.m imports "TargetA-Swift.h" in build TargetA and works fine I want to import Foo.m into TargetB build does not work fine because "TargetA-Swift.h" does not exist for TargetB I have created a "Foo-Swift.h" that "Foo.m" can import that conditionally imports either "TargetA-Swift.h" or "TargetB-Swift.h"based on compile time flags. I think there should be a better way and we should be allowed to rename the Swift -> Obj-C headers that Xcode generates the precedent already exists for renaming the Objc-C -> Swift Header We provide Xcode. Opinions? (rdr: 18063617)
|
# ? Aug 19, 2014 20:45 |
|
Regarding lazy loading: In some cases I've found it's nice to allow for recalculation of a property by nilling out its backing store. So in Obj-C: Objective-C code:
1. Since lazy properties are only calculated once, how could this be done in Swift? 2. Or is this a bad habit of mine and there's a better way?
|
# ? Aug 21, 2014 17:58 |
|
You just need to make a private optional property backing a property with a getter. The @lazy sugar isn't going to satisfy every imaginable use case.
|
# ? Aug 21, 2014 18:18 |
|
lord funk posted:Regarding lazy loading: You're describing a cache that stores transient data. Lazy properties just lazily calculate a stored property's initial value, to defer expensive work or make use of information that isn't available when the object is initialized.
|
# ? Aug 22, 2014 18:29 |
|
two things I could do in PHP that I guess I can't in swift? 1 . omit curly braces if i'm just doing one line below an if statement 2. if statements that create a variable and return false if unsuccessful so this should not work: pre:if (var joke = speaker.TellJoke?()) println(joke) else println("that creature can't tell jokes")
|
# ? Sep 3, 2014 16:27 |
|
PleasureKevin posted:two things I could do in PHP that I guess I can't in swift? Correct, you can't omit braces, and this is a feature.
|
# ? Sep 3, 2014 18:01 |
|
Are there any resources, videos and such for learning swift form a beginners point of view? I have some python skills but want something from the ground up? Is it too early for this? Its so much easier to read then objC and I don't want to learn that if I can learn swift instead and get ahead of the crowd dev wise.
|
# ? Sep 3, 2014 19:45 |
|
PleasureKevin posted:two things I could do in PHP that I guess I can't in swift? You can write this: Swift code:
Requiring curly braces is one of those things that very slightly annoys you until you just get over it. The downside is that it requires some extra vertical whitespace because of the trailing brace. The main upside is that you stop wasting your life janitoring curly braces around one-line substatements that turn multi-line and vice versa; the fact that it resolves elses unambiguously is a nice side-effect. rjmccall fucked around with this message at 19:59 on Sep 3, 2014 |
# ? Sep 3, 2014 19:54 |
|
thegasman2000 posted:Are there any resources, videos and such for learning swift form a beginners point of view? I have some python skills but want something from the ground up? Is it too early for this? I know that a lot of the usual suspects in the ObjC dev community are working on books, courses, etc. One thing you have to be aware of is that Swift is still a moving target: the implementation is still maturing, of course, but much more importantly, we expect to make a number of major changes to the language and libraries over the new few years. So when you're looking for resources, look for things that you feel confident will be regularly updated; in particular, for the love of god, don't buy a physical book.
|
# ? Sep 3, 2014 19:59 |
|
rjmccall posted:I know that a lot of the usual suspects in the ObjC dev community are working on books, courses, etc. One thing you have to be aware of is that Swift is still a moving target: the implementation is still maturing, of course, but much more importantly, we expect to make a number of major changes to the language and libraries over the new few years. So when you're looking for resources, look for things that you feel confident will be regularly updated; in particular, for the love of god, don't buy a physical book. Are apple themselves working on a video tutorial series or anything? I like videos, even without boobs!
|
# ? Sep 3, 2014 20:00 |
|
thegasman2000 posted:Are apple themselves working on a video tutorial series or anything? I don't specifically know of any planned videos, but I also don't keep track of everything that the docs people are planning. I'm sure that people externally are planning videos, and I know for a fact that we (meaning both Apple generally and the language development team specifically) provide a lot of content guidance/feedback to people in the community.
|
# ? Sep 3, 2014 20:24 |
|
Is there an especially expedient way to report issues with ObjC->Swift header issues before things start getting real next week? I filed rdar://18206277 for some UILabel issues, and I'm wondering where I should file similar issues.
|
# ? Sep 3, 2014 20:24 |
|
If you're filing bugs now with the expectation that they'll be fixed in the first official release build, I'm not sure what to tell you. That said, if you're concerned that bugs that don't get fixed right now will take six months before they show up in a build you can use, then... well, I shouldn't speculate, but I hope you're not disappointed on that front.
|
# ? Sep 3, 2014 20:33 |
|
eschaton posted:Correct, you can't omit braces, and this is a feature. What a shock that someone at Apple specifically noticed http://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/ and thought mitigating it might be an idea
|
# ? Sep 3, 2014 20:37 |
|
We designed it this way two years before that bug came out, but it's certainly a great reminder of why this is the right thing to do. It's also a great cudgel for convincing systems engineers to actually take advantage of the tools we give them.
|
# ? Sep 3, 2014 21:21 |
|
rjmccall posted:We designed it this way two years before that bug came out, but it's certainly a great reminder of why this is the right thing to do. It's also a great cudgel for convincing systems engineers to actually take advantage of the tools we give them. I am into this, cause every time I write a simple statement like if (a) b() I am tempted to write it like that. Then I rethink it and add the braces, but then I'm like, this is too busy looking plust the braces aren't necessary. Being forced to make the right choice is sometimes a gift, at least if you're a huge idiot like I am.
|
# ? Sep 7, 2014 02:04 |
|
I'm writing a keyboard extension in Swift and installed the GM on my phone to try it out. I wiped DerivedData and cleaned everything just to be on the safe side, but now I can't get the extension to start at all. All I see is this in my device logs:code:
quote:Signed OS X App Extensions may emit dyld warnings and fail to launch. But I've done that and still have the problem. I even get this on a brand new project with just the basic storyboard and keyboard extension generated by default. The only potential oddity I can think of is that the containing app is Obj-C (for historical reasons) and the extension is Swift. Anyone else run into this and come up with a fix? EDIT: Upon further inspection, it looks like it's a problem that only manifests for Obj-C container apps with Swift extensions. If I create a new Swift app with a Swift extension, it starts fine. Not sure why this stopped working (it was fine as of Xcode beta 7) or what the cleanest fix (some combination of build settings, hopefully) is. Flobbster fucked around with this message at 06:36 on Sep 10, 2014 |
# ? Sep 10, 2014 06:07 |
|
What if you put some trivial bit of Swift code in the app? I've noticed a "copying Swift standard library" compiler step go by during the betas, I wonder if that's not getting triggered for some reason.
|
# ? Sep 10, 2014 07:39 |
|
Flobbster posted:I'm writing a keyboard extension in Swift and installed the GM on my phone to try it out. I'm creating a keyboard extension too (and from your previous posts I suspect we're both building a unicode character picker), but all in ObjC - and when I installed the GM mine wouldn't start either. I'm just gonna create a new project from scratch too, I think.
|
# ? Sep 10, 2014 14:43 |
|
pokeyman, it looks like adding a dummy Swift class to my app container did the trick, thanks (I was too tired to try it last night). Feels hacky, but I guess no hackier than fudging the linker settings manually, and this was faster.duck pond posted:I'm creating a keyboard extension too (and from your previous posts I suspect we're both building a unicode character picker), but all in ObjC - and when I installed the GM mine wouldn't start either. I'm just gonna create a new project from scratch too, I think. THE BATTLE IS ON (good luck with yours!) What kind of errors are you getting on your end?
|
# ? Sep 10, 2014 14:56 |
|
You probably just need an empty Swift file in the app; no need to even put a dummy class in it. You basically just need to fool the build system. Please file that, though! Also, you'll notice that we also released beta ETA: Haha, I know the real names of our operating systems, honest. rjmccall fucked around with this message at 23:40 on Sep 10, 2014 |
# ? Sep 10, 2014 18:40 |
|
rjmccall posted:ETA: Haha, I know the real names of our operating systems, honest. "Butthead National Park"
|
# ? Sep 11, 2014 00:03 |
|
Flobbster posted:THE BATTLE IS ON For the record I'm on holiday in Turkey and working over dodgy hotel WiFi, so I'm doing this on hard mode . It's a miracle I was even able to download the GM at all... Flobbster posted:What kind of errors are you getting on your end? The app is starting up fine, but when I run the extension on its own it crashes before the debugger even starts talking to it... Hrm. I'll figure it out. Also holy moly I regenerated the project and was wondering where the LaunchImage.xcassets was, turns out it's LaunchImage.xib now (!) That's pretty cool.
|
# ? Sep 11, 2014 07:04 |
|
It would have been nice to know a few months ago that iTunes was going to be rejecting Swift libraries targeting iOS 7.
|
# ? Sep 13, 2014 23:59 |
|
Plorkyeran posted:It would have been nice to know a few months ago that iTunes was going to be rejecting Swift libraries targeting iOS 7. I'm pretty sure we fully support iOS 7 as a target. Maybe there's a bug in the submission process?
|
# ? Sep 14, 2014 04:06 |
|
The error message when submitting is just "Invalid Info.plist value. The value for the key 'MinimumOSVersion' in bundle {framework name} is invalid. The minimum value is 8.0" and it happens only if the framework contains any Swift code. Maybe just a miscommunication somewhere about what was supported? Sideloading the ipa to an iOS 7 device works fine.
|
# ? Sep 14, 2014 04:29 |
|
Yeah, I don't know what that's about; I'm sure you're not alone in seeing it, but please file it.
|
# ? Sep 14, 2014 09:04 |
|
I'm following the Ray Wenderlich tutorials and I don't think I understand this passage.Ray Wenderlich posted:Finally, select your table view, and select the sixth Inspector (the Connections Inspector). You’ll see two entries for dataSource and delegate – drag the buttons to the right of those over to your view controller in the Document Outline.
|
# ? Sep 15, 2014 16:52 |
|
PleasureKevin posted:I'm following the Ray Wenderlich tutorials and I don't think I understand this passage. This is more an Apple programming question than a Swift one, but I think he means to connect those outlets to your controller (which, in real terms, means setting properties of the source object to point to the instance of your controller class that will get dynamically created during NIB loading), which you do by control-dragging from one to the other.
|
# ? Sep 15, 2014 17:13 |
|
Is this a Swift issue or something I'm doing wrong?code:
code:
|
# ? Sep 19, 2014 20:09 |
|
Glimm posted:I think one shouldn't be making NSError's without a domain and code (the NSError that brought this to my attention is from someone elses test case), but the fact that it is possible makes me think I should be able to handle it gracefully. Am I missing something simple here? This seems like an SDK issue. When Swift imports an ObjC class, it gets all the initializers declared anywhere in its class hierarchy. This is the right default, because it's quite common for ObjC classes to inherit initializer signatures from their superclasses without explicitly redeclaring them in their @interfaces. In some cases, however, this is problematic, because the class's invariants require it to be initialized in a certain, subclass-specific way. That's what's happening here, and the right fix is probably for NSError to redeclare -init and mark it unavailable. In the meantime, yeah, you just need to be careful to not create NSErrors that way.
|
# ? Sep 19, 2014 23:48 |
|
rjmccall posted:This seems like an SDK issue. When Swift imports an ObjC class, it gets all the initializers declared anywhere in its class hierarchy. This is the right default, because it's quite common for ObjC classes to inherit initializer signatures from their superclasses without explicitly redeclaring them in their @interfaces. In some cases, however, this is problematic, because the class's invariants require it to be initialized in a certain, subclass-specific way. That's what's happening here, and the right fix is probably for NSError to redeclare -init and mark it unavailable. OK, good to know - thanks!
|
# ? Sep 19, 2014 23:59 |
|
I just got the Xcode 6 public release. I can't make new Cocoa applications with Swift as the language-- only iOS applications. I have googled around a bit and not gotten much. What gives?
|
# ? Sep 20, 2014 05:35 |
|
fleshweasel posted:I just got the Xcode 6 public release. I can't make new Cocoa applications with Swift as the language-- only iOS applications. I have googled around a bit and not gotten much. What gives? OS X gains Swift in Xcode 6.1, which is currently in beta (accessible to paid-up iOS devs and OS X devs). Presumably that'll get a public release alongside Yosemite.
|
# ? Sep 20, 2014 06:04 |
|
Yep. Swift's C/ObjC importer relies in some places on the exact contents of the SDK, and there were changes made to support us in the Yosemite SDK that were not backported to the Mavericks SDK. With such a small gap between releases, we felt that it was better to concentrate on providing a good experience on a single reliable SDK than to try to support a less-vetted SDK for a month. You can, of course, still target a minimum deployment version of Mavericks while using the Yosemite SDK.
|
# ? Sep 20, 2014 07:15 |
|
|
# ? May 15, 2024 03:32 |
|
So what's the deal with Swift's weird generic limitations? I'm trying to define a simple (imperative) expression-tree type of class hierarchy. I already can't use algebraic datatypes because I can't do something like:code:
code:
code:
Volte fucked around with this message at 13:34 on Sep 20, 2014 |
# ? Sep 20, 2014 13:09 |