Just one more thing - Swift thread - The Something Awful Forums

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Just one more thing - Swift thread

«‹›48 »

lord funk: Feb 16, 2004

So my Metal app is completely hosed. Is the correct way to convert this

code:

let vertexData = UnsafeMutablePointer<Vertex3DIn>(vertexBuffer.contents())

...to Swift 3 syntax by doing this?

code:

let vertexData = vertexBuffer.contents().bindMemory(to: Vertex3DIn.self, capacity: vertexBuffer.length / MemoryLayout<Vertex3DIn>.stride)

vertexBuffer is a MTLBuffer

edit: yeah that seems right. Back to undecipherable GPU errors.

lord funk fucked around with this message at 01:37 on Feb 6, 2017

# ? Feb 5, 2017 23:19

Adbot: ADBOT LOVES YOU

# ? May 4, 2024 23:53

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

It took us a good 3-4 days of converting from 2.3 and 3.0 and then another week of tracking down horrible bugs.

It's what we get for using a young, active language.

# ? Feb 7, 2017 21:28

dc3k: Feb 18, 2003; what.

This may be of interest https://medium.com/airbnb-engineering/getting-to-swift-3-at-airbnb-79a257d2b656#.hlcs617ke

# ? Feb 9, 2017 01:02

lord funk: Feb 16, 2004

dc3k posted:

This may be of interest https://medium.com/airbnb-engineering/getting-to-swift-3-at-airbnb-79a257d2b656#.hlcs617ke

Thanks that was a good read.

# ? Feb 9, 2017 02:56

ManicJason: Oct 27, 2003; He doesn't really stop the puck, but he scares the hell out of the other team.

Doh004 posted:

It took us a good 3-4 days of converting from 2.3 and 3.0 and then another week of tracking down horrible bugs.

It took me a similarly long time to convert, but somehow everything worked except trying to use Cocoalumberjack for a mixed project. Should I be scared that I have not yet found the horrible bugs?

# ? Feb 9, 2017 07:27

brap: Aug 23, 2004; Grimey Drawer

It seems like something went wrong if you can't import a compiled module written in swift 2 from swift 3. I'm sure there's something I don't know, but goddamn.

# ? Feb 9, 2017 08:02

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

fleshweasel posted:

It seems like something went wrong if you can't import a compiled module written in swift 2 from swift 3. I'm sure there's something I don't know, but goddamn.

It's called a lack of ABI compatibility? The fact that Swift doesn't have binary compatibility between compilers (yet) has been a big issue large codebases for a while now.

# ? Feb 9, 2017 12:59

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

fleshweasel posted:

It seems like something went wrong if you can't import a compiled module written in swift 2 from swift 3. I'm sure there's something I don't know, but goddamn.

Incompatible ABI. Conscious decision, not something unintentional.

# ? Feb 9, 2017 13:00

Kallikrates: Jul 7, 2002; Pro Lurker

I had a terrible time with the migrator mostly because (foolishly?) we were writing swift 3 style api in anticipation of the migration under swift 2.3. and the migrator clobbered our style guide enforced API.

I ended up running some of the tasks via regex for enum renaming then and de-targeting all the swift files and running it incrementally. Took longer but minimized the diffs.

Only issue we had was related to the change in Cell Reuse under ios10 sdk.

# ? Feb 9, 2017 14:44

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

ManicJason posted:

It took me a similarly long time to convert, but somehow everything worked except trying to use Cocoalumberjack for a mixed project. Should I be scared that I have not yet found the horrible bugs?

Nah, just make sure anything that goes from IB to the code behind still works properly. When they changed up the parameter conventions, the converter missed several places that now required an "_" in its signature (but still compiled just fine as expected).

# ? Feb 9, 2017 17:06

uncle blog: Nov 18, 2012

Any way to set the placeholder text color of textFields and textViews programmatically?

I added this extension I found somewhere, but using the attribute on my textFields doesn't seem to do anything.

code:

extension UITextField{
    @IBInspectable var placeHolderColor: UIColor? {
        get {
            return self.placeHolderColor
        }
        set {
            self.attributedPlaceholder = NSAttributedString(string:self.placeholder != nil ? self.placeholder! : "", attributes:[NSForegroundColorAttributeName: newValue!])
        }
    }
}

# ? Feb 14, 2017 10:27

Toady: Jan 12, 2009

There's a thread on the mailing list where people are advocating reverting SE-0025 and insisting that there's "near unanimous agreement" that we should go back to Swift 2's behavior. I've been happily using private/fileprivate since Swift 3 came out, so maybe I'm out of the loop. What's wrong with it?

# ? Feb 18, 2017 19:55

Kallikrates: Jul 7, 2002; Pro Lurker

Roughly some people want language features to control access while others are fine/prefer coding/architecture conventions. One example on the convention side is using more - smaller, modules as units of code, but that approach is cumbersome for app development and has other trade offs.

I was a fan of the older style, if anything I would only have added type private instead of what happened with private/fileprivate. I would have liked the ability to break apart declarations. Thats a personal organization preference though.

# ? Feb 18, 2017 20:46

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

Current private doesn't include extensions. Some people really love splitting things into extensions, so they run into this limitation all the time, and they want some access level that works for them; they seem torn whether that's just in the file or across the project. Of course, an access level that grants access to an arbitrary extension, combined with the fact that anything can add an extension, is not much of an access restriction at all.

I think the core team increasingly sees private vs. fileprivate as a mistake precisely because it opened the floodgates to this kind of stuff, where people want more and more fine gradations. The "convention is king" people have a point that at some point you have to trust developers not to screw with things they shouldn't, although I would not go so far as to remove both of these completely. Also, even if the language gave you perfectly precise tools for access control, e.g. "you can only use this declaration from X, Y, and Z", that wouldn't actually be good language design, because it encourages the worst habits of programmers (tedious, obsessive accounting in pursuit of "correctness") for no good reason; arguably this is already the case with private and fileprivate, because the difference isn't really important and it's easy to need to flip back and forth as you write code (chiefly because of extensions not being covered). I think we were hoping that fileprivate would be a lot more rare and thus communicatively valuable, but we undermined that because of the lazy 2-to-3 migration that just made everything fileprivate. So now it just seems like an arbitrary minor distinction that encourages bad habits in both programmers and designers.

# ? Feb 19, 2017 00:22

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

It's a textbook example of the bike shed problem.

I hadn't considered the "promotes bad programmer tendencies" aspect before. As someone who dgaf I that argument persuasive.

And yeah, the migrator making everything fileprivate was an unforced error.

# ? Feb 19, 2017 01:41

dc3k: Feb 18, 2003; what.

pokeyman posted:

And yeah, the migrator making everything fileprivate was an unforced error.

Such a pain. After our migration we're left with 19 billion fileprivate declarations and it's really annoying to get everyone to update to the proper declarations as they find them. We either end up with pull requests polluted with irrelevant changes, or have to spend time going through each file to fix it all. :sigh:

# ? Feb 19, 2017 01:48

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

dc3k posted:

Such a pain. After our migration we're left with 19 billion fileprivate declarations and it's really annoying to get everyone to update to the proper declarations as they find them. We either end up with pull requests polluted with irrelevant changes, or have to spend time going through each file to fix it all.

Dare I say, having 19 billion declarations are a problem in itself

# ? Feb 19, 2017 03:25

Kallikrates: Jul 7, 2002; Pro Lurker

I tried the migrator at first but most of the diffs needed to be rolled back - switched to a more hands on approach. I found the compiler provided fixme's to be way more accurate only prompting fileprivate when absolutely needed. I was pretty happy with the experience compared to older migrations.

# ? Feb 19, 2017 04:20

dc3k: Feb 18, 2003; what.

Powaqoatse posted:

Dare I say, having 19 billion declarations are a problem in itself

That's a valid statement. Our code base is loving enormous for not great reasons.

# ? Feb 19, 2017 05:54

Toady: Jan 12, 2009

The argument of a slippery slope toward finer gradations is a fair point. I was confused by the thread's claims that it's "actively harmful" and adds "cognitive load." I haven't felt confused or even really thought much about it beyond occasionally changing a private to fileprivate to share something.

# ? Feb 19, 2017 19:05

dizzywhip: Dec 23, 2005

The cognitive load argument, I think, comes from the desire to keep your access levels as restrictive as possible. If you move some fileprivate property from one scope to another, does it still need to be fileprivate or can it be private now? It's not a huge burden to think about, and those situations probably don't even come up that often in practice, but it's still kind of a nuisance.

My view is that there's not much value in restricting access to a scope vs. restricting it to a file, so it's not worth the additional complexity and minor cognitive overhead. I'm never concerned about something within a file being accessed by anything within the same file, and I'm not really sure why anyone would be. I also just really like file-scoped access because it works well with how I organize my code in Swift, and I find "fileprivate" to be pretty gross aesthetically, so I don't like typing it or seeing it.

I don't find the argument that private should function like it does in other languages very compelling either. Clinging to how other languages work hinders progress, and I just don't see a scenario where a developer coming from another language is harmed by the old private behavior. So I'll be very happy to see fileprivate go if that ends up happening.

# ? Feb 19, 2017 20:57

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

I was probably too influenced when SE-0025 came up by my sympathy for some guy who had enormous files that he wanted to incrementally adopt access control in. Old private is not a good match for that, but it doesn't matter: the right approach is to start by splitting the file.

# ? Feb 19, 2017 22:34

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?

While I'm a very strident advocate of files as primary source artifacts (for tool generality), imbuing the files themselves with meaning rather than their pure content seems like the wrong direction to go.

# ? Feb 19, 2017 23:12

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

Fortunately we have an easy out without breaking source compatibility; revert private to its old behavior and make fileprivate a synonym.

Not all changes will be winners; that's true whether the change comes from behind closed doors or from an open community-driven process. The important thing is that we recognize when this is the case and fix it.

Personally I'd like to see more use of experimental things behind feature flags so we can get real-world experience before we commit but there are obvious downsides to that.

Simulated fucked around with this message at 23:42 on Feb 19, 2017

# ? Feb 19, 2017 23:38

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

eschaton posted:

While I'm a very strident advocate of files as primary source artifacts (for tool generality), imbuing the files themselves with meaning rather than their pure content seems like the wrong direction to go.

I would argue that access control is primarily a tool of code organization. Well-designed access control still allows you to write whatever code you would have written, it just forces you to organize it a certain way. It's that act of organization that gives you the real benefits of access control, because having to modify the original component forces you to recognize that that's what you're doing, and so it encourages you to think of your change's effect on that component divorced from what you're trying to accomplish elsewhere. That's what gives you tighter interfaces and stronger invariants and better layering and more re-usable components.

Given that it's a tool of organization, it makes sense for it align with the "physical" aspects of organization: projects and libraries and files.

# ? Feb 20, 2017 00:03

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

I wish I had a nickel for every thread full of bad ideas about access control on swift-evolution right now.

The obvious right thing to do is admit that SE-0025 was a bad idea and roll it back. Nobody needs scoped access vs. file-private access�you're only protecting yourself from yourself. It's a pointless distinction and if you need it, your files are too drat big.

File-private could also be argued to be protecting oneself from oneself compared to internal, but as someone who works on a project that involves codegen, without control over which module a user adds those files to, file-private is very nice to hide details.

I'm not wading into these conversations though until they die down a bit. Get jobs, people!

# ? Feb 21, 2017 17:56

Kallikrates: Jul 7, 2002; Pro Lurker

It would be an interesting Case Study if this is when a Swift Evolution undos a Swift Evolution. It seems the people most vocal on the list about it seem to be pro adding even more levels...

# ? Feb 21, 2017 18:34

Toady: Jan 12, 2009

Flobbster posted:

The obvious right thing to do is admit that SE-0025 was a bad idea and roll it back. Nobody needs scoped access vs. file-private access�you're only protecting yourself from yourself. It's a pointless distinction and if you need it, your files are too drat big.

That came up in the thread amongst all the hyperbole and noise. "Big" is subjective, and sometimes you're not working on files you wrote. The most reasonable suggestion to me was to make the compiler warn about unnecessary uses of fileprivate to better match the intent of the original proposal and allow the team to gauge legitimate usage. But I'm coming from the position of having never had an issue with private/fileprivate.

Simulated posted:

Fortunately we have an easy out without breaking source compatibility; revert private to its old behavior and make fileprivate a synonym.

Wouldn't this break?

code:

class ContrivedExample {
    private func foo() {}
}

extension ContrivedExample {
    private func foo() {}
}

Toady fucked around with this message at 19:32 on Feb 21, 2017

# ? Feb 21, 2017 19:15

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

Toady posted:

Wouldn't this break?

code:


class ContrivedExample {
    private func foo() {}
}

extension ContrivedExample {
    private func foo() {}
}

If somebody does something that dumb, they deserve to be broken :v:

# ? Feb 21, 2017 19:44

Toady: Jan 12, 2009

Flobbster posted:

If somebody does something that dumb, they deserve to be broken

I can picture someone reusing a name (accidentally or otherwise) because the previous declaration was a hidden detail they didn't know they would need to consider in the event that private's behavior was reverted.

Toady fucked around with this message at 21:54 on Feb 21, 2017

# ? Feb 21, 2017 20:17

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

My understanding is that there are implementation bugs with the visibility limits on private anyway that make things like this not always work. That's... surprising and shameful, but it does maybe mean that we don't have to worry about that so much.

# ? Feb 21, 2017 21:46

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

Why can't I do this?

Swift code:

protocol P {
    var maybe: Int? { get }
}

class C: P {
    let maybe: Int = 5
}

I get:

code:

error: type 'C' does not conform to protocol 'P'
class C: P {
      ^

note: candidate has non-matching type 'Int'
    let maybe: Int = 5
        ^

which is fair enough, but Swift promotes T to T? seemingly everywhere else. Is this case different enough from the others that it can't/shouldn't be done? Or is it feasible and nobody's gotten around to implementing it yet?

I feel like this must have come up on swift-evolution or in JIRA but I cannot find anything. It is kinda hard to search for because as soon as you put "optional" and "protocol" in a sentence you get optional protocol methods which is a different thing entirely.

# ? Feb 28, 2017 21:02

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

That probably should be allowed, yeah. Although obviously it can only work when the protocol requirement is non-settable.

# ? Feb 28, 2017 22:45

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

Cool, I'll open a ticket.

# ? Feb 28, 2017 23:51

Kallikrates: Jul 7, 2002; Pro Lurker

I want a swift mailing list where I can filter subjects containing text. The filter expires after a certain amount of time. Also certain email addresses can break through the filter.

# ? Mar 7, 2017 00:29

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

I don't think it has auto-expiring filters, but the other parts can be done easily with gmail.

# ? Mar 7, 2017 01:10

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

Thanks for open-sourcing swift-stdlib-tool!

# ? Mar 22, 2017 02:49

Moogs: Jan 25, 2004; Proceeds the Weedian... Nazareth

So this is a stupid noob question, but I'm a stupid noob... when I'm making an iMessage extension, how do I control what it looks like when it's half screen (like when you have Messages open and hit the app button to switch to it) and when it's full screen? I think the answer is view controllers, is that right?

# ? Apr 9, 2017 23:33

Rudest Buddhist: May 26, 2005; You only lose what you cling to, bitch.; Fun Shoe

Yep! Sounds like you might be able to handle this through the storyboard though?

FWIW I whipped up a little iMessage extension for a 1099 contract not too long ago and used the RayWenderlich iOS 10 book to figure it all out. You get a free copy of the book if you sign up for his video stuff which is $20 month. It's pretty good, the GCD / Operations videos were great. https://videos.raywenderlich.com/courses

Maybe the other people in here have some good tips for resources too?

# ? Apr 10, 2017 00:08

Adbot: ADBOT LOVES YOU

# ? May 4, 2024 23:53

Huckleduck: May 20, 2007; giving you the hucklebuck

Quick question about using Swift as a script. I made an XCode project file with the Swift Package Manager. The purpose of the script is to contact a server and download some files, then write those files to disk. This is an async operation, but scripts end whenever they let go of the main thread. I've tried three things, one of which worked.

1. I tried to make a Dispatch Semaphor (a counting one, value of 0) and iterated it in the completion block of my async call in the script. This did not work, somehow the completion block never came back.
2. I tried using Dispatch Group. I made a group, entered the group, all the usual jazz, left the group in the completion block of the script and made a dispatch wait with a timeout. The timeout always gets hit, the completion group never comes back.
3. I made a property called "isDone" outside the function, setting it to false. Inside the async function's completion block I set it to true. Then, I grabbed the current runloop, then made an autorelease pool. In the autorelease pool I have a while loop that does nothing, but it does hold onto the main thread until isDone is true. This actually works. :how:

I realize that #3 here is jank, and in my defense I did #1 and #2 first - I have worked with GCD and am 95% sure I have all the elements in place. Is it not working because of the weirdness of running this script through Terminal?

# ? Apr 10, 2017 05:55

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Just one more thing - Swift thread

«‹›48 »