|
emoji posted:Whatever it is, Xcode crashes very hard at the moment I attempt to package.loadlib using the raw symbol, tho not reliably. That's LLDB being killed because it's trying to read memory it's not allowed to for code signing reasons, or something along those lines. Please file a bug.
|
#
?
May 11, 2016 17:10
|
|
|
|
| # ? May 15, 2024 10:47 |
|
|
Please file that as a bug. My guess is that something (the Lua JIT?) is producing corrupt runtime metadata for the code it's loading, but obviously LLDB shouldn't crash, and equally obviously that shouldn't bring down Xcode. I suspect I'm going to need to design and implement the C-interface-export feature as part of landing the calling convention this summer. But that's not for certain. It depends on what you mean by "killing". I think you're probably right in terms of shrinking the third-party ecosystem. The first-party ecosystem is committed to supporting both languages, but that probably will not last forever. But there's no plausible direction that removes binary compatibility for Objective-C applications — ever, really.
|
|
#
?
May 11, 2016 17:11
|
|
|
Subjunctive posted:I sure hope so. Well the way it is happening compromises new swift code because it has to work with people's existing code. Good ObjC code is still good, and ironically enough swift got me into it but I've never had to deal with terrible messes. emoji fucked around with this message at 17:23 on May 11, 2016 |
|
#
?
May 11, 2016 17:21
|
|
|
emoji posted:Well the way it is happening compromises new swift code because it has to work with people's existing code. Good ObjC code is still good, and ironically enough swift got me into it but I've never had to deal with terrible messes. Well, the incompatible-version churn of Swift has to stop at some point soonish, I think (I haven't kept up with published plans if any). Swift code in The Ecosystem will shed its Obj-C interoperability overhead as the set of people who need that interop declines. We're still a fair ways from adopting Swift at all, let alone replacing all of our Obj-C with it, but just as you can have extern "C" boundaries around a C++ library, I can imagine chokepoints that let the core of the app develop without worrying about Obj-C interop.
|
|
#
?
May 11, 2016 17:32
|
|
|
eschaton posted:That's LLDB being killed because it's trying to read memory it's not allowed to for code signing reasons, or something along those lines. Please file a bug. 26224565
|
|
#
?
May 11, 2016 19:12
|
|
|
IMO C++/Objective-C++ interop would be a big deal towards adopting it, at least in the minority (?) of shops that make extensive use of either. ComponentKit is dependent on Objective-C++ because the initialization syntax is superior, and no inline hierarchical markup syntax exists for us to use. I imagine if this were not the case there would be a massive effort to migrate to it ASAP.
|
|
#
?
May 11, 2016 21:24
|
|
|
Subjunctive posted:Well, the incompatible-version churn of Swift has to stop at some point soonish, I think (I haven't kept up with published plans if any). Swift code in The Ecosystem will shed its Obj-C interoperability overhead as the set of people who need that interop declines. We're still a fair ways from adopting Swift at all, let alone replacing all of our Obj-C with it, but just as you can have extern "C" boundaries around a C++ library, I can imagine chokepoints that let the core of the app develop without worrying about Obj-C interop. I did my best with SE-0058 but it got deferred. It would have made bridging to Objective-C a lot nicer. My current plan is to poke apinotes and see if there is any hope in that direction.
|
|
#
?
May 11, 2016 23:58
|
|
|
Subjunctive posted:I sure hope so.  I wasn't that heavy into Swift, but as I've used it more I really, really dig it, and wish I could use it for my full stack (  ). I can't wait for the server-side frameworks to mature - I'd love to swap out Flask for, say, Vapor.
|
|
#
?
May 12, 2016 01:42
|
|
|
Ender.uNF posted:I did my best with SE-0058 but it got deferred. It would have made bridging to Objective-C a lot nicer. My current plan is to poke apinotes and see if there is any hope in that direction. All of these questions are somewhat tied together. The interesting thing about that protocol is that it's (almost) exactly the right protocol for changing the bridging of an arbitrary C type, not just ObjC classes, and that's a pretty useful thing to consider having. It's just that there are other important questions about bridging that we have to resolve first — for example, do we need to design bridging protocols to fit into the dynamic-cast system, or are we going to just remove all of that and make dynamic cast only respect natural subtyping? And should we separate both directions of mapping?
|
|
#
?
May 12, 2016 03:21
|
|
|
squidgee posted:
rjmccall can you confirm or deny that the wwdc surprise will be compiling swift to js so that we never have to use any other language?
|
|
#
?
May 12, 2016 03:41
|
|
|
Plorkyeran posted:rjmccall can you confirm or deny that the wwdc surprise will be compiling swift to js so that we never have to use any other language? Jesus Christ don't even joke about that. The hordes of js developers might hear you and actually attempt that monstrosity!
|
|
#
?
May 12, 2016 04:55
|
|
|
Ever since I've started learning Swift I wish everyday JavaScript could just be swapped out for Swift entirely. So I'd be very excited if that happened. On the other hand you can already use Opal to compile Ruby to JavaScript so that's a good option too I guess.
|
|
#
?
May 12, 2016 07:59
|
|
|
n4 posted:Ever since I've started learning Swift I wish everyday JavaScript could just be swapped out for Swift entirely. So I'd be very excited if that happened. While that would indeed be glorious, React's popularity makes a syntax for inline component hierarchy definition a prerequisite for that. I think Apple (and others) underestimate the value in doing so. Also, speculation - I bet if webassembly becomes a thing, we'll be seeing any number of languages finally able to script the browser. I imagine writing Swift for client-side web could be feasible in two to four years.
|
|
#
?
May 12, 2016 09:35
|
|
|
quote:Shift.JS is an open source Swift to JavaScript transpiler written in JavaScript. Full documentation can be found at shiftjs.com. quote:written in JavaScript. quote:in JavaScript. Like it's even doing its own loving tokenization + AST generation. Jesus Christ.
|
|
#
?
May 13, 2016 00:28
|
|
|
The Swift compiler is right loving there guys what are you doing.
|
|
#
?
May 13, 2016 00:30
|
|
|
ultramiraculous posted:The Swift compiler is right loving there guys what are you doing. They're getting closer to the metal.
|
|
#
?
May 13, 2016 00:32
|
|
|
ES6 should just be Swift / we just need a Babel-Swift plugin for webpack. Then I can realize my fantasy of writing Swift React code.
|
|
#
?
May 13, 2016 00:54
|
|
|
Doctor w-rw-rw- posted:While that would indeed be glorious, React's popularity makes a syntax for inline component hierarchy definition a prerequisite for that. I think Apple (and others) underestimate the value in doing so. Maybe I'm misunderstanding what "a syntax for inline component hierarchy definition" is, but why don't Swift enums fit that bill? Why do you think people are underestimating the value of a syntax for inline component hierarchy definition?
|
|
#
?
May 13, 2016 01:23
|
|
|
Yeah, it's been a while since I last looked at ComponentKit, but I'm pretty sure a Swift enum with defaults for the associated values is exactly what it wants.
|
|
#
?
May 13, 2016 02:14
|
|
|
pokeyman posted:Maybe I'm misunderstanding what "a syntax for inline component hierarchy definition" is, but why don't Swift enums fit that bill? pokeyman posted:Why do you think people are underestimating the value of a syntax for inline component hierarchy definition? Andy Matuschak, ex-Apple (UIKit) posted:Q: What effect do you think Swift will have on Apple’s framework APIs? Do you expect something here in the short term? For others, I imagine it's lack of experience with the ideas, association with Javascript (though inline XML has been a thing in PHP for longer than it has in JS, and Scala does it too), and overinvestment in the wrong technology (i.e. autolayout). Doctor w-rw-rw- fucked around with this message at 06:19 on May 13, 2016 |
|
#
?
May 13, 2016 06:15
|
|
|
In a perfect world Swift would compile to WebAssembly, which could be shimmed with asm.js.
|
|
#
?
May 13, 2016 08:57
|
|
|
Doctor w-rw-rw- posted:Am I missing something? Enums can't be subclassed, and enums can't have arrays for default values. Not to mention that components can still be kind of stateful in some corner cases. I can't envision it being cleaner than Objective-C (with the C++ part for cleaner inline syntax). No, they can't be subclassed, but I figured one could deal with that using protocols. I don't know ComponentKit beyond page one of the tutorial though so I'm probably wrong about its suitability in Swift. And sure, without the syntax dickery possible in newer C++ it probably wouldn't be cleaner in Swift, but I bet you could get close. quote:It sounds to me like Apple teams (aside from devtools/compilers) struggle to push software meaningfully forward in a way other than line items in a slide on Apple's next hardware unveiling. Even if an engineer wanted to support a dramatically different but proven model for building UIs, they'd face a lot of institutional pressure against it. Some ex-Apple engineers I've talked to have expressed similar disappointments, though to be fair, them being ex-Apple, the likelihood of that is higher. Neither JS nor PHP have XML literals though? I'm not really sure what your point is here, with that or with the grousing about Apple dev teams' management. What part of ComponentKit, or React, or whatever is fundamentally untenable in Swift today?
|
|
#
?
May 13, 2016 13:15
|
|
|
pokeyman posted:Neither JS nor PHP have XML literals though? I'm not really sure what your point is here, with that or with the grousing about Apple dev teams' management. What part of ComponentKit, or React, or whatever is fundamentally untenable in Swift today? My Apple grousing was out of line. I feel frustrated at Apple because there are a couple of chasms they could cross, technologically speaking, but aren't. But they did with Swift, so...argh.
|
|
#
?
May 13, 2016 17:00
|
|
|
XHP and JSX are both preprocessor steps, though? That's kind of the opposite of a language feature. If Facebook really wanted to they could do the same thing in Swift, or even ObjC++, with an LLVM plugin to do source code transformation.
|
|
#
?
May 13, 2016 17:23
|
|
|
Or maybe at a higher level with swift gyb.
|
|
#
?
May 13, 2016 18:04
|
|
|
FYI http://thread.gmane.org/gmane.comp.lang.swift.evolution/17276 Chris Lattner posted:That said, it is also clear at this point that some of the loftier goals that we started out with aren’t tl;dr: still gonna have to include the Swift runtime for a couple of years yet
|
|
#
?
May 16, 2016 18:40
|
|
|
You would have anyway unless you've got a really aggressive deployment target.
|
|
#
?
May 16, 2016 20:08
|
|
|
I'd favor correctness / thoroughness (is that a thing with ABI?) and stability over a rush job. Plus still going to be targeting ios9 for awhile.
|
|
#
?
May 16, 2016 20:58
|
|
|
Yeah, there's still a TON of stuff in the Generics Manifesto that needs to get done and would certainly have big impacts on the ABI. I'm glad they're not rushing it.
|
|
#
?
May 16, 2016 22:21
|
|
|
rjmccall posted:You would have anyway unless you've got a really aggressive deployment target. Yes, of course. It just means another hypothetical year of waiting for shops that do current minus N iOS versions (or wait for % adoption to fall a sufficient amount based on that), in order to reduce app size.
|
|
#
?
May 16, 2016 23:18
|
|
|
rjmccall posted:All of these questions are somewhat tied together. The interesting thing about that protocol is that it's (almost) exactly the right protocol for changing the bridging of an arbitrary C type, not just ObjC classes, and that's a pretty useful thing to consider having. It's just that there are other important questions about bridging that we have to resolve first — for example, do we need to design bridging protocols to fit into the dynamic-cast system, or are we going to just remove all of that and make dynamic cast only respect natural subtyping? And should we separate both directions of mapping? Oh yes, it totally makes sense for Swift as an open source project. It just sucks for me personally because now I have to write a lot more glue code. Not the end of the world by any stretch.
|
|
#
?
May 17, 2016 02:36
|
|
|
Doctor w-rw-rw- posted:Yes, of course. It just means another hypothetical year of waiting for shops that do current minus N iOS versions (or wait for % adoption to fall a sufficient amount based on that), in order to reduce app size. I'm sure Facebook is 123mb and Yelp is 74mb because of swift dylibs....
|
|
#
?
May 18, 2016 08:32
|
|
|
emoji posted:I'm sure Facebook is 123mb and Yelp is 74mb because of swift dylibs.... I know what you're trying to say but you're kind of correct, except the opposite of that.
|
|
#
?
May 18, 2016 11:05
|
|
|
Does Swift have tail-call optimization? Googling gives conflicting answers.
|
|
#
?
May 22, 2016 00:21
|
|
|
It will sometimes do tail calls; it does not promise to do so.
|
|
#
?
May 22, 2016 04:24
|
|
|
So what's the point of sizeof being wrong and strideof being sizeof?
|
|
#
?
May 23, 2016 19:55
|
|
|
The size is the amount of memory it takes to store the type, and the stride is the distance between two values of the type in an array. C defines those the same way, but we don't, and the term applies better to the first.
|
|
#
?
May 23, 2016 21:06
|
|
|
rjmccall posted:The size is the amount of memory it takes to store the type, and the stride is the distance between two values of the type in an array. C defines those the same way, but we don't, and the term applies better to the first. I know what they do... what is the point of having sizeof as defined in Swift exposed to the user? Just to pack stuff a bit more tightly? sarehu fucked around with this message at 21:23 on May 23, 2016 |
|
#
?
May 23, 2016 21:19
|
|
|
Neither of them is something users generally need to be using directly, but if you're going to hand-roll memory layout for some reason, you need both to get optimal packing / reproduce Swift's results. Also, sizeof(T) is the amount of memory you're allowed to touch given an arbitrary pointer to a T; strideof(T) may affect adjacent values depending on what the pointer is to.
|
|
#
?
May 23, 2016 21:28
|
|
|
|
| # ? May 15, 2024 10:47 |
|
|
rjmccall posted:Also, sizeof(T) is the amount of memory you're allowed to touch given an arbitrary pointer to a T; strideof(T) may affect adjacent values depending on what the pointer is to. Okay on that note I'll retract calling sizeof(T) "wrong." On the other hand if you're optimizing struct packing like this, sizeof(Int) could stand to be 4 bytes to save some cache line space...
|
|
#
?
May 23, 2016 21:41
|
|