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

«‹›2 »

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

I love you rjmccall.

# ¿ Jun 2, 2014 20:08

Adbot: ADBOT LOVES YOU

# ¿ May 2, 2024 03:00

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

pokeyman posted:

Presumably since it's the same runtime and ABI (? or a transparent FFI) one could deploy compiled Swift on to old versions of iOS and OS X?

This is my big question about Swift.

# ¿ Jun 2, 2014 20:24

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

rjmccall posted:

tuples

Yes.

# ¿ Jun 2, 2014 21:03

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

rjmccall posted:

Everything is public for now. We expect to have basic access control for 1.0.

Ok cool, I came here to ask this. The lack of documentation about access control at all had me worried that the answer was "use a bunch of anonymous functions".

# ¿ Jun 3, 2014 07:35

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

Ocrassus posted:

Was/is there any relation between the language 'Swift' and the code name attributed to the CPU in the A6 SoC (also swift).

IIRC A7 is Cyclone.

'yeah I'm working on swift right now'

'Sorry which division?'

Seems like cross wires or a coincidence?

I'm pretty sure rjmccall mentioned it was a recent marketing name.

# ¿ Jun 3, 2014 19:25

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

Is there any plan to build out the collections a bit more? I'm necessarily asking if you're going to do completely reimplement Scala's collection library, but man would that be convenient sometimes.

# ¿ Jun 4, 2014 11:50

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

So is having a recursive inner function supposed to be possible? I was trying to write an inner function that called itself, and got a full a full-on compiler abort. Just this simple example breaks things:

code:

class Example {
	
	//LLVM ERROR: Broken function found, compilation aborted!
	func breaksCompiler() {
		func innerFunction() {
			innerFunction()
		}
	}

	//Error: "Variable used within it's own initial value"
	func givesError() {
		let innerFunction: ()->Void = {
			innerFunction()
		}
	}

}

The error case was my second attempt, and the error is reasonable. I'm just wondering if the first case should give an error and doesn't, or if it should be working.

Edit: Radar'd the compiler error (rdar://17165028)

ultramiraculous fucked around with this message at 01:11 on Jun 5, 2014

# ¿ Jun 5, 2014 01:00

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

Meat Street posted:

Sanity check before I file a radar:

code:

func fibonacci(n: Int) -> Int {
    func fibonacciStep(a: Int, b: Int, n: Int) -> Int {
        if (n > 0) {
            return fibonacciStep(b, a+b, n-1)
        } else {
            return a
        }
    }

    return fibonacciStep(0, 1, n)
}

This should be perfectly legal, right? It crashes Xcode every time as written above, but if I don't nest the functions it works just fine.

e: finally got it to spit out an error instead of crashing:

code:

Playground execution failed: error: Execution was interrupted, reason: EXC_BAD_ACCESS (code=1, address=0x1).
The process has been left at the point where it was interrupted, use "thread return -x" to return to the state before expression evaluation.
* thread #1: tid = 0x4b7f8b, 0x0000000000000001, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1)
  * frame #0: 0x0000000000000001

I ran into the same thing and rjmccall said it was a bug. I'd file another radar for it, if you have the time.

# ¿ Jun 8, 2014 11:34

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

Meat Street posted:

rjmccall (or anyone else), I'm curious: do you have any recommendations as far as getting up to speed on the more functional side of things? Obviously it doesn't have to be Swift-specific. Last time I tried Learn You A Haskell it flew over my head, but maybe I should give it another shot now that I have some more concrete motivation

The Coursera course on Scala is a pretty good starting point if you really want to get broken down and start looking at things functionally.

# ¿ Jun 9, 2014 13:16

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

Any idea why this is an issue?

code:

let seq: Sequence = ["1"]
seq.generate() //Error: 'Sequence' does not have a member named 'Generate'

I'm trying to do some generic collection extensions and this is causing me some trouble.

# ¿ Jun 12, 2014 01:34

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

rjmccall posted:

There are some soundness restrictions about what you can do involving associated types (including Self) when you just have a protocol value.

In this case, we could heroically let you iterate through and bind the elements to Any or something, so feel free to file a bug.

Is there a reason that Array and Dictionary and whatnot implement only the vanilla Sequence instead of something like SequenceOf<T> (if it wasn't a structl)? Same for Generators (IndexingGenerator, etc) and GeneratorOf<T>. It mostly just seems like all the collections share common roots like Sequence, but they ditch some type information along the way.

# ¿ Jun 12, 2014 04:20

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

So it seems like there's no Swift changes in this XCode beta, right? Do you have any picture of how changes to the language will be advertised, even if it's just XCode change logs?

# ¿ Jun 18, 2014 06:19

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

rjmccall posted:

Well, @lazy isn't thread-safe, either, although the lazy initialization of globals is.

Woah what. Why is it not thread safe in both cases? It seems like either situation is a place where you'd do a dispatch_once if you were doing it yourself.

# ¿ Jun 18, 2014 08:39

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

Choadmaster posted:

Thread safety is expensive. I've rarely ensured it in my own lazy-loaded properties unless necessary. I'd make a joke about making atomic properties the default but Ender.uNF would be displeased.

Lazily calculating a property isn't quite as bad as making everything atomic though. An @lazy variable is presumably initialize-once, use-everywhere deal, which mean it's only atomic on the front end/first retrieval. After the value is calculated, dispatch_once is basically a conditional and a return from there on out.

I mean the case in the book, if I recall, is that you have some sort of expensive child that might have to be initialized. If Thread 1 and Thread 2 both try to use that resource around the same time, should it initialize once for each thread? What if that resource has state associated with it?

# ¿ Jun 18, 2014 10:53

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

Axiem posted:

While fiddling around recently, I realized that Swift has built-in Array and Dictionary classes, but no corresponding Set class. Is there any particular reason for the omission? Are Sets just not used often enough to justify making a Swift counterpoint to NSSet? Or have I simply missed something in the docs?

See:

lord funk posted:

Question for rjmccall: will there be a Swift version of sets?

rjmccall posted:

Almost certainly.

# ¿ Jul 2, 2014 18:27

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

dizzywhip posted:

I'm pretty sure they said that access control won't be in for 1.0.

That or the complete opposite:

rjmccall posted:

Everything is public for now. We expect to have basic access control for 1.0.

# ¿ Jul 7, 2014 19:33

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

ljw1004 posted:

The release notes for Xcode beta 3 say "The online Swift Programming Language documentation and book has been updated. See: https://itunes.apple.com/us/book/the-swift-programming-language/id881256329?mt=11"

But that link only shows that the book was "published June 2nd, updated June 12th"

Any ideas on how to get the updated book? or ideas when it will be released?

I'm guessing that's just a caching thing. My iBook appears to be updated (chagelog please?) based on the file's modified date, but the iBooks store shows the old date. Based on how long it takes App Store releases to propagate, it seems like it's similar iTunes weirdness that'll fix itself eventually.

Based on those XCode release notes, I'm liking the changes.

# ¿ Jul 7, 2014 19:46

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

Speaking of arc4random, is there any plan for standard library functionality re: random numbers? arc4random being 32-bit in a 64-bit environment isn't great to start with, and the unsafe pointers stuff is kinda/intentionally gross but necessary when you're using arc4random_buf to get a bunch of random values.

# ¿ Jul 15, 2014 05:37

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

rjmccall posted:

It's an obvious thing to improve, but there are a lot of more important things to do first.

Yeah, that sounds reasonable to me. I threw up rdar://17674726 as a follow up.

# ¿ Jul 15, 2014 06:07

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

dizzywhip posted:

I'm super happy about the private(set) access modifier, I was really hoping for something like that.

Yeah, it like it. Seems like a nice improvement over all the private category extensions I've written over the years.

# ¿ Jul 21, 2014 22:12

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

rjmccall posted:

Is this abomination rjmccall approved now or something?

# ¿ Jul 30, 2014 07:43

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

http://www.jessesquires.com/apples-to-apples-part-two/

drat, ladies. Things are getting Swift!

# ¿ Aug 6, 2014 23:29

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

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

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

Random benchmark-y question, but is there a reason that the array of optionals in this case would consistently sort more quickly:

code:

class Number {
  var value: Int
  init(_ value: Int) {
    self.value = value
  }
}

let collectionOpt: [Number?] = (0..<10000).map( { _ in Number(Int(arc4random_uniform(1 << 20))) })
let collection: [Number] = (0..<10000).map( { _ in Number(Int(arc4random_uniform(1 << 20))) })

func perfMeasure(label: String, work: () -> ()) {
  var startTime = NSDate.timeIntervalSinceReferenceDate()
  for _ in 0..<100 {
    work()
  }
  NSLog("\(label): [%.03f ms]" , (NSDate.timeIntervalSinceReferenceDate() - startTime) * 1000 )
}

func testArray() {
  perfMeasure("testArray") {
    var a = Array<Number>(collection)
    a.sort({$0.value < $1.value})
  }
}

func testContiguousArray() {
  perfMeasure("testContArray") {
    var a = ContiguousArray<Number>(collection)
    a.sort({$0.value < $1.value})
  }
}

func testArrayWithOptionals() {
  perfMeasure("testArrayWithOptionals") {
    var a = Array<Number?>(collectionOpt)
    a.sort({$0!.value < $1!.value})
  }
}


testArray()
testContiguousArray()
testArrayWithOptionals()

Changing Number to a struct makes the [Number?] array perform slower, which seems like what you'd expect. I'm assuming it's something specific to arrays of references.

# ¿ Jan 23, 2015 10:02

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

Yeah, this is with -O. The numbers actually come out "right" with -ONone, but it also takes 10x longer :-P

So this is a pretty representative result from an rMBP:

code:

Class:
testArray: [855.361 ms]
testArrayWithOptionals: [711.702 ms]

Stuct:
testArray: [113.779 ms]
testArrayWithOptionals: [168.950 ms]

Basically the Struct version behaves like you'd expect, where the optionals are slightly slower, presumably because of the optionality bit needing to get read/checked for each comparison.

The class version of [Number] consistently coming in slower than the [Number?] one is baffling a few people.

# ¿ Jan 23, 2015 19:39

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

Kallikrates posted:

Over and over when talking about swift I hear the phrase "I heard from a guy..." or "So-and-so said..." about things that are important in using a language and when you ask where they got it from, silence.

Yeah, I've been guilty of referring to rjmccall as "some Swift engineer on Something Awful", and I routinely hear people reference Apple dev forums posts that have been lost to time.

# ¿ Jan 31, 2015 01:48

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

Subjunctive posted:

That was an OK post.

I liked it

# ¿ Feb 6, 2015 02:56

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

Incremental compilation!!! :dance:

# ¿ Feb 9, 2015 20:22

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

rjmccall posted:

There's a huge amount of bad taste and cargo-culting in the functional community. It's a "well, we're functional programmers so we're obviously a cut above the rest, now here's an unnecessary monstrosity of syntax that's worse than anything in perl" sort of thing. There is a reason that "advanced" Haskell and Scala look the way they do, and it is not because that is somehow core to the mathematical purity of the model.

Always remember that as a programmer your goal is to write good code that solves problems, not to make your job more interesting by finding clever ways to eliminate keystrokes. It's something we're all susceptible to, but it's a bad instinct.

What you mean scalaz's ★ operator doesn't mean "monad transformer" or whatever to most people?

# ¿ Feb 16, 2015 09:19

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

Look Around You posted:

What about the ☆ one?

e: seriously having a star as an operator is dumb enough, but then having a filled one and a hollow one as operators is even loving worse. IIRC they're related too?

Yeah they were both related to the same operation with modads. Phone posting, but I have a horrible feeling that they represented opposite prefix/postfix operator affinity (or at least there was another horrible operator that was like that).

Just because you can, doesn't mean you should.

ultramiraculous fucked around with this message at 07:09 on Feb 17, 2015

# ¿ Feb 16, 2015 22:21

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

Rewrite the whole thing in WebObjects.

# ¿ Feb 26, 2015 22:34

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

Doh004 posted:

Fully aware of good, proven, image caches out there, definitely. Decision was to run our own so I do as I'm told!

Rolling your own cache is never, ever, not a bad idea.

# ¿ Mar 6, 2015 00:49

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

Yeah I ran into that at some point. You can't make a half open interval where the start is not included, and you can't make one where the end is greater than the start (i.e. Double.infinity..<0.0). It seems like an <.. or a more relaxed HalfOpenInterval is what's needed.

Edit: Relatedly, I tried to make a <.. operator earlier and got stuck on this:

code:

// Expected '{' after operator name in 'operator' declaration
// Braced block of statements is an unused closure 
infix operator <.. {
    associativity none
    precedence 135
}

I completely ripped that off from the Swift headers, but I'm getting the sense that using "." in an operator might not exactly work?

ultramiraculous fucked around with this message at 15:47 on Jun 23, 2015

# ¿ Jun 23, 2015 10:27

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

There was a kinda neat Scala library that did all of that too:

https://github.com/zzorn/ScalaQuantity

# ¿ Jun 26, 2015 00:42

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

It may not solve your exact issue, but everyone in the world should be using chisel:

https://github.com/facebook/chisel

# ¿ Aug 16, 2015 01:06

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

Is there any plan for any sort of preprocessing steps in the future? I'm thinking up to even Scala's macros, where we could run arbitrary Swift on the code as a build step. It seems like it'd be nice to have to something like C#'s async/await transforms.

# ¿ Oct 1, 2015 21:44

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

This is probably more for rjmccall directly, but is there a way to get lldb to know about C types you'd usually use in the ObjC world? Mostly I'm trying to fix Chisel to deal with being on a Swift frame in the debugger while trying to execute an ObjC expression. What I'm seeing is if you run "expr -l ObjC++ -- (NSInteger)1", it works when you're in an ObjC or ObjC+Swift Xcode target, but in a strictly-Swift one it fails out saying "use of undeclared identifier 'NSInteger'". Is there a way to get lldb to pull in the ObjC stuff at runtime?

# ¿ Oct 23, 2015 07:32

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

Subjunctive posted:

Congrats, rjmccall!

# ¿ Dec 3, 2015 19:25

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

rjmccall posted:

My hope, and to a degree my expectation, is that the Foundation APIs will evolve in a Swiftier direction as the community begins to drive that development; but they're a fine basis from which to start the discussion.

So loving pumped for this, rjmccall.

# ¿ Dec 3, 2015 19:41

Adbot: ADBOT LOVES YOU

# ¿ May 2, 2024 03:00

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

Ender.uNF posted:

And a million comments on the first commit. It's highly annoying.

Gotta make that impact. Get your name out there!

# ¿ Dec 3, 2015 22:07

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

«‹›2 »