Rumor: Apple's "iPad Pro" to be as thin as an iPhone, sport 12.2-inch display & extra speakers

189101214

Comments

  • Reply 221 of 261
    shsfshsf Posts: 302member
    Quote:

    Originally Posted by CanukStorm View Post

     

    Actually, it'll be Spring;

     

    http://www.macrumors.com/2014/11/02/apple-watch-spring-ahrendts/

     

    This is via 9to5mac, so I would click on the 9to5mac link in that article as well.




    Great shopping period spring is and they 'll have time to make the required battery improvements. I would also think that they might be having some issues sourcing the safire front now that the AZ plant has gone bust. Looks lovely btw. 

  • Reply 222 of 261
    shsf wrote: »
    canukstorm wrote: »
     
    Actually, it'll be Spring;

    http://www.macrumors.com/2014/11/02/apple-watch-spring-ahrendts/

    This is via 9to5mac, so I would click on the 9to5mac link in that article as well.


    Great shopping period spring is and they 'll have time to make the required battery improvements. I would also think that they might be having some issues sourcing the safire front now that the AZ plant has gone bust. Looks lovely btw. 

    The official Apple line is early 2015. That could be between January and June 2015 for the Apple Watch.
  • Reply 223 of 261
    mr omr o Posts: 1,046member

    The 12" iPad Pro could be more productive for creative pro's than the 11" Macbook Air.

     

    Throw in continuity and you might have a disruptive product for creative professionals: You could switch between Adobe illustrator on your iMac and your iPad pro.

     

    Apple should team up with Adobe. And have a brief look at wacom's graphic tablet.

  • Reply 224 of 261
    knowitallknowitall Posts: 1,648member
    Ya' wanna' see sumpin' ...

    To me this just amazing!

    I wrote an OS X app that displays this:

    Swift is extremely powerful.
    It has the power of C++ without the crappy millions of language constructs, special characters and keywords and utter crappy (sometimes impossible) debugging.
  • Reply 225 of 261
    mr. h wrote: »
    Your Surface Pro 3 is clearly defective and has some kind of serious hardware problem. It is not valid to judge a product based on a single instance that is obviously broken.

    Like the Xbox 360 RRoD?
    Yeah all it takes is a "single instance" to lose a customer.
  • Reply 226 of 261
    I agree generally, though I'm not sure that a larger screen will necessarily be huge. Apple won't want to make it too big, or it will be unwieldy.

    You say that but then there's a 5.5 inch iPhone that tries to pass itself off as useable in one hand... and fooling no one.
  • Reply 227 of 261
    mr. hmr. h Posts: 4,870member
    mr. h wrote: »
    Your Surface Pro 3 is clearly defective and has some kind of serious hardware problem. It is not valid to judge a product based on a single instance that is obviously broken.

    Like the Xbox 360 RRoD?
    Yeah all it takes is a "single instance" to lose a customer.

    Weren’t all Xbox 360s that had the RRoD replaced free of charge?

    If a manufacturer guarantees that a device is checked thoroughly before shipment and absolutely will not be dead on arrival, or fail for any reason in the first x years of ownership, then and only then is it valid to judge a product by the failure of a single instance.

    However, that is not how mass-produced electronics work. If you make 500,000 of something, to thoroughly check each one individually before shipping would massively increase the cost. If when you use a device and it appears to be defective, you should get the manufacturer to replace it, not winge about it on a forum and write off the product as crap. Now, if the manufacturer refuses to replace the product or sends lemon after lemon as replacements, then we have valid cause for complaint.
  • Reply 228 of 261
    mr. hmr. h Posts: 4,870member
    knowitall wrote: »
    Ya' wanna' see sumpin' ...

    To me this just amazing!

    I wrote an OS X app that displays this:

    Swift is extremely powerful.
    It has the power of C++ without the crappy millions of language constructs, special characters and keywords and utter crappy (sometimes impossible) debugging.

    Those interested in the discussion on Swift may like to check out the relevant section of John Siracusa’s Yosemite review.
  • Reply 229 of 261
    Quote:

    Originally Posted by Suddenly Newton View Post

     
    Quote:

    Originally Posted by Benjamin Frost View Post



    I agree generally, though I'm not sure that a larger screen will necessarily be huge. Apple won't want to make it too big, or it will be unwieldy.




    You say that but then there's a 5.5 inch iPhone that tries to pass itself off as useable in one hand... and fooling no one.

     

     

    True. Even Apple can make mistakes.

  • Reply 230 of 261
    solipsismysolipsismy Posts: 5,099member

    True. Even Apple can make mistakes.

    I'd love to have mistakes that yield me billions in profit.
  • Reply 231 of 261
    solipsismy wrote: »

    True. Even Apple can make mistakes.

    I'd love to have mistakes that yield me billions in profit.

    There's no proof that the Plus has yielded Apple a penny, but nice try.
  • Reply 232 of 261
    solipsismysolipsismy Posts: 5,099member
    There's no proof that the Plus has yielded Apple a penny, but nice try.

    Do you want to lock in your comment that the iPhone 6 Plus is a financial mistake for the company?
  • Reply 233 of 261
    solipsismy wrote: »
    There's no proof that the Plus has yielded Apple a penny, but nice try.

    Do you want to lock in your comment that the iPhone 6 Plus is a financial mistake for the company?

    Hot air from Cook means nothing. Only hard facts count. When you can provide those, then we'll talk.

    Until then, Mr. Novice Poster:

    zip it.
  • Reply 234 of 261
    solipsismysolipsismy Posts: 5,099member
    Hot air from Cook means nothing. Only hard facts count. When you can provide those, then we'll talk.

    Until then:

    zip it.

    Right, because Cook is always lying during those conference calls¡ :rolleyes: Can you show one time where he's lied to his shareholders or is just your new anti-Apple, pro-homophobia stance now that Cook came out as gay?
  • Reply 235 of 261
    solipsismy wrote: »
    Hot air from Cook means nothing. Only hard facts count. When you can provide those, then we'll talk.

    Until then:

    zip it.

    Right, because Cook is always lying during those conference calls¡ :rolleyes: Can you show one time where he's lied to his shareholders or is just your new anti-Apple, pro-homophobia stance now that Cook came out as gay?

    Why would Cook be anti-Apple as their CEO?

    What you suggest is Cook's new stance doesn't make sense.

    If I were you, I'd take my friendly advice for now and zip it.
  • Reply 236 of 261
    dasanman69dasanman69 Posts: 13,002member
    Why would Cook be anti-Apple as their CEO?

    What you suggest is Cook's new stance doesn't make sense.

    If I were you, I'd take my friendly advice for now and zip it.

    Isn't it like 3 AM in the UK? Get some sleep. You're starting to sound delirious. :lol:
  • Reply 237 of 261
    mr. h wrote: »
    knowitall wrote: »
    Ya' wanna' see sumpin' ...

    To me this just amazing!

    I wrote an OS X app that displays this:

    Swift is extremely powerful.
    It has the power of C++ without the crappy millions of language constructs, special characters and keywords and utter crappy (sometimes impossible) debugging.

    Those interested in the discussion on Swift may like to check out the relevant section of John Siracusa’s Yosemite review.

    Whoa! Thanks for the link ... I've been reading that epistle -- but hadn't gotten that far!

    Safe, Fast, Succinct, Fun -- all describe Swift ...

    But the fact that Swift * is written in Swift says it all.

    * and in the future, the OS X, iOS and Server Operating Systems ...


    I suspect that the Apple/IBM partnership will yield a lot of OS code to enable new capabilities in mobile/desktop/server apps.
  • Reply 238 of 261
    MarvinMarvin Posts: 15,273moderator
    But the fact that Swift * is written in Swift says it all.

    * and in the future, the OS X, iOS and Server Operating Systems ...

    The Swift library of functions is written in Swift at least, I didn't see details of the Swift runtime/interpreter/compiler. I doubt they'd transition a whole OS over but it depends on the benefits. If there was a 10-20% performance hit but the code ended up being significantly smaller making up some of the performance loss and the rest with embedded C code, there's a possibility. Quite a lot of work if it was just for the sake of it. Even though it doesn't support C++, if there's a quick translation app to convert C++ code into Swift this can work out ok. I'd at least like Applescript to be deprecated in favor of Swift and have a migration in XCode from one to the other. Switching Automator over would be nice too. If they had something like this, you could batch actions externally to apps more easily e.g batch actions on images using Photoshop, Pixelmator etc.
  • Reply 239 of 261
    shsfshsf Posts: 302member
    I 've heard all available frameworks are currently in swift too, though I could be wrong.
  • Reply 240 of 261
    Marvin wrote: »
    But the fact that Swift * is written in Swift says it all.

    * and in the future, the OS X, iOS and Server Operating Systems ...

    The Swift library of functions is written in Swift at least, I didn't see details of the Swift runtime/interpreter/compiler. I doubt they'd transition a whole OS over but it depends on the benefits. If there was a 10-20% performance hit but the code ended up being significantly smaller making up some of the performance loss and the rest with embedded C code, there's a possibility. Quite a lot of work if it was just for the sake of it. Even though it doesn't support C++, if there's a quick translation app to convert C++ code into Swift this can work out ok. I'd at least like Applescript to be deprecated in favor of Swift and have a migration in XCode from one to the other. Switching Automator over would be nice too. If they had something like this, you could batch actions externally to apps more easily e.g batch actions on images using Photoshop, Pixelmator etc.

    shsf wrote: »
    I 've heard all available frameworks are currently in swift too, though I could be wrong.</span>

    Here’s the process for compiling code for an x86-64 CPU using clang, Apple’s LLVM-based C/C++ and Objective-C compiler:

    1000


    Clang compiler
    Instructing swiftc to show the LLVM IR for our Swift add() function doesn’t illuminate much. You’ll see a call to llvm.sadd.with.overflow.i64, which is the LLVM equivalent of the x86-64 addq instruction seen in the earlier assembly code. We want to know how the compiler makes the leap from adding two variables of type Int to calling the fast, native 64-bit addition instruction, whether that’s in LLVM IR or in x86-64 machine code.

    The Swift compiler introduces another step and another intermediate form into the compilation process: Swift Intermediate Language (SIL). Here’s the process for compiling Swift code for an x86-64 CPU using swiftc:

    Swift compiler

    1000

    ... [Examples of code generation and optimization by SIL -- directly mapping to instructions in the LLVM IR or passing instructions to be included in-line to the LLVM IR]

    Now, finally, we have all the pieces. Builtin is the gateway between Swift and LLVM IR. The types and functions exposed by Builtin have direct mappings to types and instructions in LLVM IR. The transparent attribute denotes functions that are primitive enough that they should always be inlined. Generating LLVM IR from SIL code that uses Builtin types and calls Builtin functions is straightforward: Builtin.Word is an LLVM i64 (or an i32 when targeting a 32-bit architecture; SIL is more target-independent than LLVM IR); sadd_with_overflow_Word is the llvm.sadd.with.overflow.i64 intrinsic function, and so on.

    This exploration has revealed something else. The Swift standard library actually is a little special (beyond just being loaded by default). Though it is indeed written in Swift, the standard library is the only thing that has access to the world of Builtin functions and types. It also uses the transparent attribute to mark certain functions for automatic inlining.

    http://arstechnica.com/apple/2014/10/os-x-10-10/22/
    It’s not a stretch to imagine that Apple’s plans for Swift extend from the source code all the way down to not just the machine code generated by the compiler but also the design of the CPU itself. At various times in the past, specific hardware features of PowerPC, x86, and ARM processors have influenced the efficiency of fundamental aspects of Apple’s platform, from function calling conventions to features of the Objective-C runtime. I would be surprised if Apple hasn’t already lobbied for (or directly implemented, in the case of its own chip designs) CPU features that are tied directly to its compiler, language, and runtime stack. I expect even more of this in the future.

    http://arstechnica.com/apple/2014/10/os-x-10-10/23/


    No way I can prove this, but I am under the impression that the frameworks are all being rewritten in Swift ... Initially, Swift bridged to the underlying Obj-C, C++, C frameworks -- but that seemed to change with each release of Xcode ... Apparently, New Swift Frameworks sit side-by-side with the existing Obj-C, C++, C frameworks -- at some point I suspect the Swift frameworks will be the only ones maintained and Obj-C apps will bridge to them.
Sign In or Register to comment.