jckarter

Looking at the generated code, we have a couple issues that prevent full optimization. One of them I already knew about (https://bugs.swift.org/browse/SR-2926) -- as a debugging aid, we guard every trap we emit with the equivalent of an `asm volatile("")` barrier, because LLVM will otherwise happily fold all the traps together into one trap. We really want every trap to have a distinct address so that the debugger can map that trap back to the source code that emitted it, but the asm barrier prevents other optimizations as well. As for `reduce`, it looks like the compiler does inline away the closure and turn the inner loop into what you would expect, but for some reason there's more pre-matter validation of the array than there is with a for loop. That's a bug; by all means, reduce is intended to optimize the same.

Clay has shared and unique pointer implementations in its library. Naive channels could be mostly implemented in the library as well, but I think they might need language support to pull some of the tricks Rust and Go do to make them fast, and Clay's type system would need to better guard against unintended sharing to make them safe. The Rust and Go developers are contributing the groundwork for lightweight tasks into LLVM, so with runtime library support Clay could potentially inherit that support. I think a region type system would fill in the safety holes; the Deca language (http://code.google.com/p/decac/) is very similar to Clay (no runtime requirements, variant-based dynamic dispatch) and successfully uses region typing to provide safe memory access.

Clay is a lot more flexible and metaprogrammable than Rust. Clay allows ad-hoc overloading with predication based on arbitrary compile-time computation, whereas Rust's polymorphism support is more strictly based on Hindley-Milner parametric polymorphism and type classes. On the other hand, Rust, by baking features like shared/unique pointers and logging into the language, is able to provide much stronger safety guarantees with a much simpler type system than Clay would need to provide the equivalent guarantees. Rust also requires a runtime, which supports some cool features like lightweight tasks, cycle collection, and builtin logging, whereas Clay sticks to a "no runtime other than libc" mandate. Overall, Rust will probably be a much better choice for large-scale application development than Clay. The cool thing about Clay is that it's like a scripting language for LLVM. It's great for flexibly generating small amounts of native code without runtime dependencies.

What build information is missing? The README.txt describes how to build the compiler; it's a fairly typical cmake setup.

You're correct; Clay's type system doesn't help much with memory safety. It's flexible enough to express RAII-based ownership semantics like C++, so you can manage dynamic memory with reference counted, uniquely-owned, or other policy-enforcing pointer objects, but also like C++, the language doesn't prevent you from taking nonowning references to arbitrary data behind the type system's back and using those references after the owning object has freed the data.

The more fundamental mismatch is that they're testing an interpreter (libc's printf implementation) against a compiler (pypy's format string jit). A C++0x or D library that parsed format strings at compile time would likely still beat pypy.

If you're banned here, you aren't locked out of the site or prevented from posting. Your posts are just marked so that only you (and other users who have chosen "show dead comments" in their preferences) can see them, and there's no indication that you've been blacklisted. It's terrible.

jashkenas (CoffeeScript author) replied to you, but for some reason he's deadbanned:

> Thanks for mentioning it -- the fix was actually to correct a regression from a previous commit, not a true bugfix versus 1.0.1. I've removed that line from the changelog.

It's C++ and of course dependent on Unix/Windows memory mapping APIs, but you might like asmjit: http://code.google.com/p/asmjit/

Sad, but understandable. "OpenBSD writes their own ROFF interpreter" isn't very interesting, but "OpenBSD purges C++ from core" appeals to developers' strong emotional responses toward C++.

Not everywhere needs to become Silicon Valley. IT is well-trodden ground with established players and power centers now. Smaller cities like Portland would do better promoting emerging industries than trying to catch up to the web startup bus 15 years after it left the station.

I see. So does this purge only consist of compiled executables then, with the standard C++ headers and libstdc++ still getting a pass?

Orthogonal to bloat, libstdc++ is a large, ugly, and hard-to-audit attack surface that I'm sure OpenBSD is glad to push out of core.

Every Mac still ships with Xcode on the OS install disc, as do the OS X upgrade discs. Let's wait until Lion comes out before assuming that won't be the case anymore.

The language in the standard may have changed in C99 due to unprototyped functions being deprecated. In C89, however, I'm pretty sure that unprototyped and prototyped functions need to have compatible calling conventions. In practice, there's no platform I know of where a prototyped function cannot be called as a variadic or unprototyped function (barring special platform-specific ABIs like stdcall that weren't designed for C). Some RISC-style ABIs with pass-by-register and shadow space will fail in the reverse case (a variadic function called as a fully prototyped function) since the shadow space doesn't get populated by the caller for a fully prototyped function, but for a variadic call site, both the shadow space and parameter registers will be populated, specifically to allow prototyped functions to be called as unprototyped.

This is incorrect. It's not possible to implicitly use an incompatible ABI for prototyped and vararg functions, since a foo f(bar, bas) function needs to be callable via an unprototyped foo (* )() pointer. Thus, even prototyped C functions need to use a caller-cleanup convention. To use the callee-cleanup convention, the entire Win16 and Win32 apis are annotated with explicit __stdcall attributes and are addressed by distinctly-typed (__stdcall * ) function pointers, of which no vararg variation is allowed.

I wonder if they'll stick to this for the final version. They tried to remove 256-color mode support in 10.5.something but backpedaled when the Mac Starcraft players went nuts.

There are lots of edge cases where the sign of zero affects computation. In floating-point, zero values represent not only the exact value zero but the result of an underflowed computation too small to represent as a non-zero floating point value, so retaining the sign is often important to at least keep such computations on the correct side of a branch cut or limit. For example:

x/+0 = +infinity

x/-0 = -infinity

sqrt(+0) = 0

sqrt(-0) = nan

log(+0) = -infinity

log(-0) = nan

That's just for the framebuffer. All the intermediate textures flying around will need four times the memory too, and could easily eat up several hundred megabytes.

Crackers aren't your customers. Don't waste time/money on them.

A big difference between iOS and OS X is that desktop applications have more than 20 years of UI research and convention behind them, while touch interfaces have less than half (maybe even less than a quarter) that. There's thus a lot more room for experimentation in touch interfaces since there isn't as large a body of best practices. Apps that try to go their own way UI-wise on OS X are more than likely going to end up subtly violating the norms of OS X application behavior that standard Cocoa apps all follow implicitly, much like Qt apps on OS X do. Indeed, Gruber's example of Twitter 2 already misbehaves in a number of head-scratching ways: among the ones I've noticed, hitting cmd-W from the tweet list hides the entire app rather than closing the tweet window, and the "compose tweet" box floats over everything even when the app is in the background. I think the tolerance for UI annoyances like these is a lot lower, and apps that try to go their own way are going to expose them a lot more than apps that stick to the tried and tested standard widgets.

There's actually a dedicated Script menu available in the OS. Instead of deploying .apps and taking up space in the Dock, you can start up AppleScript Editor and check "Show Script menu in menu bar" in its Preferences. Then place your scripts in ~/Library/Scripts (or ~/Library/Scripts/Applications/<application name> to have them only appear while a certain application is active).

"copy"ing an immutable string just retains it, so there's little benefit to using a retain property for NSString properties, or for properties of the other NSMutableCopying type families. As a best practice you should always use copy properties for them.

Aside from a tiny VM written in C++, nearly all of Factor (http://factorcode.org/), including its parser, optimizing compiler, and code generator, is written in itself. The author of Clay (http://tachyon.in/clay/) is working on a new version of its compiler written in itself too.

In my experience, bitbucket has been extremely unreliable and creaky compared to github. I see frequent random unscheduled outages where the ssh connection won't connect, ssh won't authenticate, or hg won't respond from the other side. The web interface also caches a lot of stuff too long; I've seen it take a few minutes for its idea of "tip" to refresh after pushing new patches, and stripped revisions linger in the log view for similar amounts of time. Hopefully now that Atlassian's bought them the service quality will improve over time.

I don't know about how that font looks on the iPad, but my first reaction looking at it on my laptop was that it looks extremely awkward with those thick character-wide serifs. I know this is a bikesheddy thing to bitch about, but I'd personally be less distracted if Writer stuck with a familiar monospace font like Vera, Monaco, or Consolas...or if, as drcode mentioned, it used a proportional font.

That the author more or less admits to confirmation bias in the very first paragraph kind of colors their conclusions, regardless of whether Ping actually sucks or not.

When you're done with that you should also read through the examples John Benediktsson's been posting to his blog: http://re-factor.blogspot.com

The area around 24th Street BART isn't so bad, and trips downtown on BART are faster and cheaper than taking the 12, 14, or 27.

There were a number of talks in that vein. Rich Hickey's talk about his experimental "pod" feature in Clojure for safe scoped mutation, Joe Pamer's talk about making F# suitable as a first-class .NET language, and Jonathan Shapiro's talk about the correctness constraints guiding BitC's design all focused more on problem domains and the features necessary to fill those domains than superficial language features.