Apple Development: iOS, macOS, Swift, Dylan

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›354 »

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Hughlander posted:

Anyone know where obj_sendmsg lookups are fully documented? I have an object that conforms to a protocol, but does not implement an optional method of it. I want to forward that method to another object, but from testing:
forwardInvocation:
resolveInstanceMethod:
forwardingTargetForSelector:

Are not being called. I want to know the rules for sendmsg of a protocol basically.

Was the answer overriding -respondsToSelector: and returning YES for the method in question?

# ? Jan 30, 2014 19:34

Adbot: ADBOT LOVES YOU

# ? Jun 5, 2024 13:35

Doctor w-rw-rw-: Jun 24, 2008

Hughlander posted:

Anyone know where obj_sendmsg lookups are fully documented? I have an object that conforms to a protocol, but does not implement an optional method of it. I want to forward that method to another object, but from testing:
forwardInvocation:
resolveInstanceMethod:
forwardingTargetForSelector:

Are not being called. I want to know the rules for sendmsg of a protocol basically.

code:

@protocol FOO <NSObject>
@optional
- (void)blah;

@end

@interface ATAppDelegate : NSObject <NSApplicationDelegate, FOO>

@end

and

code:

- (id)forwardingTargetForSelector:(SEL)aSelector
{
    if (aSelector == @selector(blah)) {
        return [NSNull null];
    } else {
        return [super forwardingTargetForSelector:aSelector];
    }
}

in the implementation seems to work just fine for me for triggering an unknown selector error on NSNull, so it looks like it works. Probably slow, though.

# ? Jan 30, 2014 19:47

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

At the runtime level, there is nothing different for a message send that resolved statically to a declaration in a protocol vs. one that resolved to a declaration in a class.

# ? Jan 30, 2014 20:08

Hughlander: May 11, 2005

rjmccall posted:

At the runtime level, there is nothing different for a message send that resolved statically to a declaration in a protocol vs. one that resolved to a declaration in a class.

I think I had a PEBKAC moment / was too tired on the bus way home when I was testing it last night. Pretty much every one of those things I said didn't work does work and now I have things like:

code:

- (id)forwardingTargetForSelector:(SEL)aSelector
{
    if (class_getInstanceMethod(self.implementationClass.class, aSelector)) {
        return [[self.implementationClass.class alloc] init];
    }

    return nil;
}

In my codebase.

# ? Jan 31, 2014 01:49

Hughlander: May 11, 2005

Doctor w-rw-rw- posted:

http://nsme.tumblr.com/post/42505049479/disable-all-exceptions-breakpoint-for-unit-tests might have some useful clues.

Thanks again 666. For google tests the magic for me was:

code:

script any('testing::internal' in s for s in [x.function.name for x in lldb.thread.frames] if s is not None) and lldb.thread.GetProcess().Continue()

# ? Jan 31, 2014 02:15

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

Doctor w-rw-rw- posted:

https://www.facebook.com/paper

The thing I spent half a year working on. It's pretty sweet. (Sorry for the double-post)

Congratulations!

# ? Jan 31, 2014 07:26

lord funk: Feb 16, 2004

Why else would a tableView cell have really slow touch response? I've set [tableView setDelaysContentTouches:NO] but it's still really, really slow.

As far as I can tell by toggling delaysContentTouches YES and NO, there is no difference whatsoever.

lord funk fucked around with this message at 16:46 on Jan 31, 2014

# ? Jan 31, 2014 16:37

Doh004: Apr 22, 2007; Mmmmm Donuts...

Anyone else run into CocoaPods breaking yesterday? I did but thought I did something wrong. Turns out I wasn't the only one?

http://blog.cocoapods.org/Repairing-Our-Broken-Specs-Repository/

# ? Jan 31, 2014 16:46

lord funk: Feb 16, 2004

Okay, I think it's the !!!*new*!!! UITableViewCellScrollView in iOS 7. Oh boy! A hidden scrollview that I had no idea was there. Just what I wanted!

Kind of want to die today.

edit: yep, that was it.

lord funk fucked around with this message at 17:38 on Jan 31, 2014

# ? Jan 31, 2014 17:32

Doctor w-rw-rw-: Jun 24, 2008

lord funk posted:

Okay, I think it's the !!!*new*!!! UITableViewCellScrollView in iOS 7. Oh boy! A hidden scrollview that I had no idea was there. Just what I wanted!

Kind of want to die today.

edit: yep, that was it.

Yeah, iOS 7 put scrollviews everywhere. And UITableViews are a gargantuan hulking mass of code. Not surprised that it has a lot of bad performance characteristics.

BTW, pokeyman -- I'm guessing a popover controller rewrite is no longer necessary?

# ? Jan 31, 2014 18:20

Doh004: Apr 22, 2007; Mmmmm Donuts...

Anyone know how Reachability actually works? I'm using the Reachability manager in AFNetworking 2.0 and I'm pretty frustrated by it. Here's how I'm testing this out:

Run app in simulator with full internet connection.
App starts up just fine, Reachability says I have internet (I've started monitoring)
Change Network Link Conditioner to the 100% Loss profile (killing internet)
Wait around, no new notifications from Reachability, okay fine
Make a "request", request times out, I check the reachabilityManager.isReachable and it still says I'm connected to the internet
Wait around ~30 seconds, finally triggers that I've lost internet connectivity

Why does this take 30 seconds for it to trigger? What's even more frustrating is the changing of the status takes time, so once I resume connectivity and I resume everything in my app, the check seems to fire again and its status hasn't updated (that it has a connection and is still unreachable) causing it to behave incorrectly.

# ? Jan 31, 2014 18:51

haveblue: Aug 15, 2005; Toilet Rascal

The system can only tell if its own network interfaces (the wifi and cellular radios) are online; if there's a problem elsewhere in the chain (like a downed backhaul line or a network link conditioner) the only way to detect that the connection is down is to send a packet and see if it reaches the other end. The notification gets delivered late because (I assume) the system noticed that your request failed, did a few probes of its own, and eventually concluded that there's something wrong with the rest of the network.

I don't know why it takes so long to recover when you restore service, but I'm guessing that's a power-saving strategy. It would take a lot of energy to send very frequent polls to a dead network and I wouldn't put it past Apple to stop client apps from polling as well.

# ? Jan 31, 2014 19:06

Filburt Shellbach: Nov 6, 2007; Apni tackat say tujay aaj mitta juu gaa!

I'm pretty sure Reachability is meant to be used only to tell the user they definitely can't access the network right now. That way you can say "hey knucklehead turn off airplane mode" immediately. Sure beats trying to starting a request then making the user sit waiting for a timeout.

# ? Jan 31, 2014 19:14

Doh004: Apr 22, 2007; Mmmmm Donuts...

Okay, that makes sense, thanks.

I guess I need to handle this kind of stuff on my own then? I could do a check every time a request comes back with a timeout. Kinda sucks because it's not necessarily indicative of a bad internet connection (maybe something on our end is too slow). Is there a way to differentiate a lack of connectivity and a regular timeout?

# ? Jan 31, 2014 19:47

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Doctor w-rw-rw- posted:

Yeah, iOS 7 put scrollviews everywhere. And UITableViews are a gargantuan hulking mass of code. Not surprised that it has a lot of bad performance characteristics.

BTW, pokeyman -- I'm guessing a popover controller rewrite is no longer necessary?

Oh still quite necessary, just haven't done anything about it yet. Maybe we can add some scroll views.

# ? Jan 31, 2014 20:33

duck pond: Sep 13, 2007

I have found that if all else fails sticking a category on UIScrollView that does this:

code:


- (BOOL)delaysContentTouches
{
    return NO;
}

- (BOOL)touchesShouldCancelInContentView:(UIView *)view
{
    return YES;
}

is sometimes the only sure fire way to prevent touch delays and/or ensure correct touch cancelling. Though in retrospect, perhaps I was running into the problem that I didn't realise there were UITableViewCellScrollViews everywhere?

# ? Feb 1, 2014 00:38

Meat Street: Oct 17, 2004; knowin' nothin' in life but to be legit

The jerking off about Paper is pretty amazing considering that the app isn't even out yet. "Xcode cannot handle our scale" seriously? Clown shoes everywhere: http://www.quora.com/Facebook-Launches-Paper-January-2014/What-was-it-like-to-help-develop-Paper/answer/Jason-Barrett-Prado

# ? Feb 2, 2014 03:59

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

Meat Street posted:

The jerking off about Paper is pretty amazing considering that the app isn't even out yet. "Xcode cannot handle our scale" seriously? Clown shoes everywhere: http://www.quora.com/Facebook-Launches-Paper-January-2014/What-was-it-like-to-help-develop-Paper/answer/Jason-Barrett-Prado

What the hell does that even mean? Paging Dr 666!

# ? Feb 2, 2014 04:45

Meat Street: Oct 17, 2004; knowin' nothin' in life but to be legit

ultramiraculous posted:

What the hell does that even mean? Paging Dr 666!

I would love to hear some inside commentary from the good doctor; there are a LOT of grandiose statements in that Quora answer.

# ? Feb 2, 2014 05:19

Glimm: Jul 27, 2005; Time is only gonna pass you by

ultramiraculous posted:

What the hell does that even mean? Paging Dr 666!

I'm guessing it means merging Xcode project files is a pain in the rear end in a large organization?

# ? Feb 2, 2014 05:40

Doctor w-rw-rw-: Jun 24, 2008

Xcode really couldn't. On a good day, Xcode could easily spend 20 minutes just indexing the project. Paper wasn't built alone; it shared a lot of code and useful abstractions with the main Facebook app. One thing I've seen when it comes to OS X programming is that a some operations are generally assumed to be free or close to it and a lot of stuff is done on the main thread. When you violate Xcode's assumptions that make sense for a normal app when the complexity of what you're dealing with is somewhere between two to three orders of magnitude greater than an average application, Xcode starts to really struggle. Don't get me wrong, Xcode is a great tool (especially Clang/LLVM), but in many ways we really did exceed its design parameters by a significant margin.

You might notice that I'm not giving many specifics. I don't yet want to speak on the record about certain technical aspects before Facebook has had a chance to announce and explain them itself through tech talks and the like - it's entitled to that. In private, I still intend to exercise some discretion as well. That said, the codebase really is chock-loving-full of really amazing infrastructure. Keep in mind that half the team worked in some capacity on the original iPhone or other performance-intensive applications at Apple, and spent a huge amount of the project's lifetime writing just the infrastructure.

The engineers on the team are legitimately some of the best in the industry - each and every one of them is in the 99.99th percentile (if not 99.999th percentile), and I've seen a lot of really good engineers. And they were on the same team, and they were given time and resources. I can say that every one of his claims is absolutely true. The app really is that nuts. For most of it, you'll have to take my word for it, unfortunately. And that's not even saying anything about the designers. Origami was built by designer Brandon Walkin, who also created BWToolkit (which is way obsolete by now, so don't take this as a suggestion to use it). He did some even more amazing stuff than that. Mike is a genius designer in ways I can't comprehend. He somehow intrinsically just knows good design, and is a Quartz Composer savant. Sharon makes things so, so beautiful.

Jason Prado posted:

...The engineering complexity here is finding a way to fully utilize the multicore architecture of newer iPhones on top of the UIKit framework which has no support for multithreading. Significant work went into creating a framework for doing rendering work on multiple threads, and we spent a long time finding the balance between performance and complexity.

This is completely true and it is positively *mindblowing*. The application's profiling characteristics are unlike anything I've ever seen, and it's so multicore that they actually had to hack the thread scheduling to optimize performance. And they created a way to (given certain criteria) do things like retain/release views* on different threads. Safely.

*handwaving a bit, but at a coarse level that's what it is

I don't think I gush about things that often, particularly not to this degree, but Paper's code 100% absolutely deserves it. It is _fucking_ _insane_. On a technical level, the most advanced iOS application in existence bar none, full stop.

Really.

Doctor w-rw-rw- fucked around with this message at 06:25 on Feb 2, 2014

# ? Feb 2, 2014 06:06

dizzywhip: Dec 23, 2005

That sounds pretty cool and all, and I'm sure it's a great technical achievement, but...was that kind of optimization really necessary? I mean I guess it had to have been or you guys wouldn't have done it, but I'm not really seeing what it's doing that's so performance intensive.

# ? Feb 2, 2014 11:09

Doctor w-rw-rw-: Jun 24, 2008

Gordon Cole posted:

That sounds pretty cool and all, and I'm sure it's a great technical achievement, but...was that kind of optimization really necessary? I mean I guess it had to have been or you guys wouldn't have done it, but I'm not really seeing what it's doing that's so performance intensive.

The answer is largely due to some secret sauce which I'll only mention after someone discovers it on their own. If you must know, you could probably jailbreak your device and profile it, then profile it some more, and let the results sink in. Alternatively, imagine what it would take to make a visually rich app's UI multithreaded, and take it to its logical conclusion. Keep in mind that Apple doesn't give large companies carte blanche to use internal APIs, the Facebook integration APIs excepted, obviously, for Facebook. No source level access to iOS, no official modifications to any Apple framework done on Facebook's behalf for the app.

Also, the goal was to hit 16ms per runloop tick as much as possible, to avoid frame drops. This is an extremely aggressive goal to hit on lower end devices.

Doctor w-rw-rw- fucked around with this message at 11:41 on Feb 2, 2014

# ? Feb 2, 2014 11:25

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

Meat Street posted:

"Xcode cannot handle our scale" seriously?

Xcode can handle a lot.

This statement makes me suspect the app's workspace contains recursive project references�projects containing references to other projects that reference the first, and so on. The place I've often seen that is if every "module" is its own project and every higher-level module contains a reference to the project that produces every lower-level module it incorporates, rather than a reference to the produced module itself.

# ? Feb 2, 2014 15:58

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Doctor w-rw-rw- posted:

The answer is largely due to some secret sauce which I'll only mention after someone discovers it on their own. If you must know, you could probably jailbreak your device and profile it, then profile it some more, and let the results sink in. Alternatively, imagine what it would take to make a visually rich app's UI multithreaded, and take it to its logical conclusion. Keep in mind that Apple doesn't give large companies carte blanche to use internal APIs, the Facebook integration APIs excepted, obviously, for Facebook. No source level access to iOS, no official modifications to any Apple framework done on Facebook's behalf for the app.

Also, the goal was to hit 16ms per runloop tick as much as possible, to avoid frame drops. This is an extremely aggressive goal to hit on lower end devices.

There's a reason Microsoft added async/await to C#. I totally buy that getting a truly responsive multithreaded UI working async would take a ton of work to get your framework right, otherwise it's a million lines of inverted spaghetti logic as cause and effect get separated all over the code.

Looking forward to more details in the future.

# ? Feb 2, 2014 17:41

a nest of hornets: Nov 17, 2012; by Ralp

I believe the hype, re: Paper and multithreading (congratulations btw!!! very jealous of the team you work with!)

Staying <16ms per tick is bad rear end. I'd really love to hear more about the thread scheduling if at all possible

# ? Feb 2, 2014 18:00

FearIt: Mar 11, 2007

I'm trying to write a C++ app that periodically takes screenshots and performs some processing on it ( without saving it to disk as part of the process ).
The code appears to be generating images that resemble the desktop, but are downsampled ( at least when the source is my retina display ).
Is there anything I can do to prevent this downsampling on retina sources?

code:

void Core::SysIO::captureScreenOSX( Image* image )
{
  CGDirectDisplayID cg_main_id  = CGMainDisplayID();
  int               cg_pix_high = (int)CGDisplayPixelsHigh( cg_main_id );
  int               cg_pix_wide = (int)CGDisplayPixelsWide( cg_main_id );
  CGImageRef        cg_image    = CGDisplayCreateImage( cg_main_id );
  CGColorSpaceRef   cg_colors   = CGColorSpaceCreateDeviceRGB();

  int   bytes_per_pix = 4;
  int   bytes_per_row = bytes_per_pix * cg_pix_wide;
  int   bits_per_comp = 8;
  char* raw_data    = new char[ cg_pix_wide * cg_pix_wide * 4 ];
  
  CGContextRef cg_context = CGBitmapContextCreate( raw_data,
                                                   cg_pix_wide,
                                                   cg_pix_high,
                                                   bits_per_comp,
                                                   bytes_per_row,
                                                   cg_colors,
                                                   kCGImageAlphaPremultipliedLast | kCGBitmapByteOrder32Big );
  
  CGContextDrawImage( cg_context,
                      CGRectMake(0, 0, cg_pix_wide, cg_pix_high ),
                      cg_image );
  
  image->data.initialize( cg_pix_high, cg_pix_wide );
  
  for( int pos_y = 0; pos_y < cg_pix_high; pos_y++ )
  {
    for( int pos_x = 0; pos_x < cg_pix_wide; pos_x++ )
    {
      int byte_idx = ( bytes_per_row * pos_y ) + pos_x * bytes_per_pix;

      Pixel* pixel = image->data.getPtr( pos_y, pos_x );
      pixel->r = raw_data[ byte_idx + 0 ];
      pixel->g = raw_data[ byte_idx + 1 ];
      pixel->b = raw_data[ byte_idx + 2 ];
    }
  }

  CGColorSpaceRelease( cg_colors );
  CGContextRelease( cg_context );
  CGImageRelease( cg_image );
  delete[] raw_data;
}

# ? Feb 2, 2014 18:13

Doctor w-rw-rw-: Jun 24, 2008

CGDisplayPixelsHigh and CGDisplayPixelsWide aren't returning you the raw number of pixels. It's scaling the value according to your screen scale.

Might want to get the value from NSScreen.

Note: [NSScreen mainScreen] is the screen that's focused (docs say: receiving keyboard events). [NSScreen screens][0] is the one that's got the menu bar.

EDIT: no, the docs recommend convert*ToBacking: - so you'll probably want to take the screen frame then convert that rect to backing using the same screen?
EDIT 2: yup.

Objective-C code:

NSScreen *screen = [NSScreen screens][0];
NSRect backingRect = [screen convertRectToBacking:[screen frame]];
NSLog(@"dims %@", NSStringFromSize(backingRect.size));

Logs "dims {2880, 1800}" on my rMBP.

a nest of hornets posted:

I believe the hype, re: Paper and multithreading (congratulations btw!!! very jealous of the team you work with!)

Staying <16ms per tick is bad rear end. I'd really love to hear more about the thread scheduling if at all possible

Heh, I share your jealousy - I'll be on the market for a job soon, actually! That said, I have nothing but good things to say about my team, and we're on good terms.

One cool tool a team member whipped up was an overlay at the top of the window that flashed yellow or red whenever something hogged the main thread for too long. He later added some debugging info for the offending operation (details are hazy, as I used it mainly for the color indicator), but it was really useful to track down CPU-hogging operations and bust them, because if you had a good enough mental model of what was happening, the color turning red could strongly hint where you should profile to find the offending expensive operation. I don't know (or remember, if he ever told me) how he implemented it, but if I had to venture a guess I think a NSRunLoop observer with a timing function would probably do the trick.

Doctor w-rw-rw- fucked around with this message at 19:46 on Feb 2, 2014

# ? Feb 2, 2014 19:28

FearIt: Mar 11, 2007

Doctor w-rw-rw- posted:

CGDisplayPixelsHigh and CGDisplayPixelsWide aren't returning you the raw number of pixels. It's scaling the value according to your screen scale.

Might want to get the value from NSScreen.

Note: [NSScreen mainScreen] is the screen that's focused (docs say: receiving keyboard events). [NSScreen screens][0] is the one that's got the menu bar.

EDIT: no, the docs recommend convert*ToBacking: - so you'll probably want to take the screen frame then convert that rect to backing using the same screen?
EDIT 2: yup.
Objective-C code:
NSScreen *screen = [NSScreen screens][0];
NSRect backingRect = [screen convertRectToBacking:[screen frame]];
NSLog(@"dims %@", NSStringFromSize(backingRect.size));
Logs "dims {2880, 1800}" on my rMBP.

Oo, you seem to be right. I hardcoded some my rMBP resolution into the cg_pix_wide and cg_pix_high, and I got the result I wanted ( a lossless 2560x1600 image ). Thank you so much!

# ? Feb 2, 2014 19:46

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

chimz posted:

You should either a) call AppleCare or b) file a bug at https://bugreport.apple.com with the file generated from 'sudo sysdiagnose' run on the command line.

If you're feeling masochistic, you might be able to see those logs using firewire debug logging:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/fwkpfv.1.html

Do you have anything attached to the system while it's sleeping?

Just in case anyone else cares about this, bug report 15965810 submitted. I'm going to try booting with "-v debug=0x100" but I don't expect anything. I'm also going to try recording the screen in high-speed mode with my iPhone to catch any debug messages that may be disappearing too quickly to notice but I have very low hopes of that being helpful.

# ? Feb 2, 2014 20:15

Doctor w-rw-rw-: Jun 24, 2008

I *may* have run into something similar recently where I left my 10.9 rMBP alone for long enough to go into hibernation I *think* - and it didn't wake up. Since I haven't seen my laptop hibernate yet, I can't really be certain.

# ? Feb 2, 2014 20:21

lord funk: Feb 16, 2004

drat. And I was chuffed with myself that I finally got my collectionview to scroll well.

# ? Feb 2, 2014 20:25

Doc Block: Apr 15, 2003; Fun Shoe

Apple needs to headhunt these guys and get them working on iOS 8.

# ? Feb 2, 2014 20:34

Doctor w-rw-rw-: Jun 24, 2008

Doc Block posted:

Apple needs to headhunt these guys and get them working on iOS 8.

Apple's people are already plenty good, iOS 7 just had an insane timetable. IMO 7.0 was released before it was fully baked, but Apple does good work. That said, some of the best people for iOS perf are (in my opinion) at Facebook.

I believe it'd take something much bigger than iOS 8 to poach them back.

# ? Feb 2, 2014 20:54

Doctor w-rw-rw-: Jun 24, 2008

BTW, it's live: https://itunes.apple.com/us/app/id794163692

vvvv
:tipshat:

Doctor w-rw-rw- fucked around with this message at 18:14 on Feb 3, 2014

# ? Feb 3, 2014 17:46

Glimm: Jul 27, 2005; Time is only gonna pass you by

Doctor w-rw-rw- posted:

BTW, it's live: https://itunes.apple.com/us/app/id794163692

This app is completely buttery. Slick as hell.

# ? Feb 3, 2014 18:05

NoDamage: Dec 2, 2000

So I guess the completely obvious has occurred... did the people at Facebook not anticipate this being an issue?

http://news.fiftythree.com/post/75486632209/every-story-has-a-name-fiftythrees-story-began

# ? Feb 3, 2014 19:07

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

NoDamage posted:

So I guess the completely obvious has occurred... did the people at Facebook not anticipate this being an issue?

http://news.fiftythree.com/post/75486632209/every-story-has-a-name-fiftythrees-story-began

I would think, in a very real sense, that to Facebook it's not an issue.

Dickish? Sure. But easily ignored.

# ? Feb 3, 2014 19:28

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

Glimm posted:

This app is completely buttery. Slick as hell.

Yeah, I'm not sure I really see it fitting into my life, but I'm definitely gonna keep playing with it just because it's so sexy.

# ? Feb 3, 2014 19:32

Adbot: ADBOT LOVES YOU

# ? Jun 5, 2024 13:35

Doctor w-rw-rw-: Jun 24, 2008

ultramiraculous posted:

Yeah, I'm not sure I really see it fitting into my life, but I'm definitely gonna keep playing with it just because it's so sexy.

Some of my favorite parts are the particle emitter that explodes when the like sound pops, the bounciness when you tear off popovers (comments, notifications, etc), and the animation when you tap the 'likes' in a post and the list expands.

# ? Feb 3, 2014 19:45

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›354 »