Comment by foljs | Hacker News Reader

Comment by foljs | Hacker News Reader

Parent Full thread

1) (a) and (b) Applies mostly to the Darwin source. Apple doesn't provide you with the latest sources before it has it released commercially. Big f'n surprise. Not many people are interested in Darwin anyways.

(c) Actually, you can get the WebKit code and build it, and you'll have a WebKit browser to run. I've done it. Don't know what you are talking about. Did you expect the whole code for Safari? They sure give enough Webkit source for Google, Nokia, the GTK people et al to build a full featured browser upon...

2) "Also, it is quite clear to everyone involved that the reason that they are actively developing Clang/LLVM is so that they can avoid gcc 4.3+, when it went GPLv3."

Actually, it is not at all "clear". They started using it way back in 2005. Actually they wanted a better, faster, more flexible and dynamic compiler infrastructure, and LLVM provided that. And they use it for other stuff too, from graphics code to MacRuby.

3) "since then, Apple's Xcode compiler has rapidly slipped out of date, and now they are forced to take over development of a BSD project just to stay competitive".

Actually Apple had made huge improvements to XCode's compiler in XCode 3, even adding several new features to the core Objective-C language, and also made a HUGE improvement to the overall IDE and compiler (new static analyzer, new debugger, AST-based syntax assistance and code completion etc) with XCode 4 (currently in public beta 5).

4) despite Apple's claims, Clang/LLVM is still very very far behind GCC in terms of correctness and compliance

Bzzz, wrong.

5) (certainly with recent specifications, like C++0x)

Which are not even standard yet, and noone cares about while actually SHIPPING code.

Whatever man...

Also, "Apple doesn't provide you with the latest sources before it has it released commercially" has nothing to do with anything I said. Where did I claim I wanted the source code to something that was unreleased?

If you want an example, as you obviously don't believe me, RIGHT NOW Apple is not in compliance with the GPL as they have not released the source code to WebCore, which is licensed under LGPL, /as shipped/ for iOS 4.1 or 4.2. They have no requirement to release WebKit (which they simply /don't/ for mobile), but they /have/ to release WebCore.

Seriously: why did /anyone/ upvote this comment? The poster was either needlessly inflammatory without any new contributions ("Bzzz, wrong"), reliant upon straw men (I never claimed to want the code to Safari or any other project that is not explicitly open source), unrelated to the conversation (lumping unrelated features into the "compiler"), or downright off-topic (discussing anything other than Apple's open source website). Please educate me here.

1) a/b: The original poster explicitly stated "on Apple's open source website", to which I also explicitly limited my statements.

1) c: Unfortunately, this is not generally true: Apple keeps an internal fork of WebKit that has numerous abilities not in their public trees, which happens to be why Android and WebOS both have totally incompatible mechanisms for adding multi-touch support to JavaScript despite iOS having been out with that functionality for years prior.

To be quite explicit, I dare you to find and recompile WebKit for iOS. Mobile is where all the action is these days, and Apple knows that: deal with it.

2) All but one of the previous gcc contributors from Apple are no longer allowed to read the gcc-patches mailing list, and they are also not allowed to work with any code from gcc 4.3+: Apple is now permanently locked at gcc 4.2 and cannot even backport changes from gcc 4.2.2 (as this was re-marked as GPLv3 when it was released). This is a serious /serious/ problem for Apple, as they /need/ a compiler.

3) I don't understand in the slightest why improvements to the debugger, an external analyzer, or better syntax completion in the IDE, have anything at all to do with the core compiler.

4) I'm sorry, but this has been my impression as a toolchain integrator and distribution vendor. LLVM, which only even supports two platforms (although having seriously broken semi-support for ARM) is often stated to be "catching up" in correctness to gcc, but is not there yet. The opinion that LLVM is somehow epic is something you only hear from incredibly pro-Apple developers. I mean, even Apple's port of gcc explicitly chooses incorrect results occasionally for performance (an interesting specific case being ___divdc3).

5) It is in "final final final draft". Meanwhile, even for C++, Clang doesn't totally work yet. Until just a couple months ago, Clang's website claimed the following:

> However, the implementation of Clang C++ is still somewhat immature, with remaining bugs that may cause compiler crashes, erroneous errors and warnings, or miscompiled code.

AFAIK, this situation has not changed since then, and my attempts to use it recently have, in fact, been met with the compiler crashing out instead of generating any code at all.

  4) I'm sorry, but this has been my impression as a toolchain integrator and distribution vendor. LLVM, which only even supports two platforms (although having seriously broken semi-support for ARM) is often stated to be "catching up" in correctness to gcc, but is not there yet. The opinion that LLVM is somehow epic is something you only hear from incredibly pro-Apple developers. I mean, even Apple's port of gcc explicitly chooses incorrect results occasionally for performance (an interesting specific case being ___divdc3).

In order to keep their user-base on Actionscript/Flash, Adobe was banking on LLVM to get Flash to work on iOS devices before they were legally restricted from doing so. With the lifting of the ban, Adobe can now deploy Flash-based code on iOS devices[1]. LLVM is also used in many other commercial software project, so your argument doesn't hold.

[1] http://www.adobe.com/devnet/logged_in/abansod_iphone.html

Compilers can be surprisingly "incorrect" and yet still be usable in production. I've routinely been forced to work with compilers that generated incorrect code in numerous situations, and I've simply cataloged and avoided them.

(Interestingly enough, the compiler in question that generated incorrect code so often that I had a catalog ruleset of "things not to do" was llvm-gcc, when I was first deploying Cydia and Telesphoreo to the jailbroken iPhone community. However, that was a while ago, and LLVM doesn't have those shockingly bad issues anymore.)

(It was just a few weeks ago, though, when chpwn started trying to get Cydia compiling with LLVM and kept getting "internal compiler error" on what seemed like some reasonably simple C++.)

Reply on news.ycombinator.com