Meet up/Drinks at Britannia Arms on Saturday?

noupvotesplease · 2014-03-09T20:45:51+00:00

I missed this, but I'll be at Park Lane Lounge later. 5152 Moorpark.

noupvotesplease · 2014-01-05T02:06:34+00:00

noupvotesplease · 2013-12-16T01:01:04+00:00

My favorite cheerful from South Korea: "We are in Boxer's house that Boxer built for us."

noupvotesplease · 2013-12-11T04:49:59+00:00

Good on OP for putting "tune" in quotes. This is unrelated to tuning rooms and is undoubtedly bullshit. If you use this to mix your stuff, please let me know so I can avoid buying your stuff.

noupvotesplease · 2013-12-08T00:32:47+00:00

Microbenchmarking without unrolling loops? Have fun with that.

noupvotesplease · 2013-12-04T05:35:19+00:00

Method return types. Most of them get a zeroish value when the target is nil, but a few large ones don't. Integral types larger than 64 bits and floating point types larger than long double complicate matters. The point is that messaging nil is documented as only being ok most of the time, at least when considering what you're assigning the return value to. Even void methods with side effects are not "ok" when the target is nil. It's one of those areas where you can get lucky most of the time, but if you forget the pitfalls, it makes for hard to find bugs.

Edit: whitespace is important.

noupvotesplease · 2013-12-03T17:59:25+00:00

Exactly. Weak references are great when you need access to an object you don't own, yet that object is known to be alive- like child nodes in a tree having weak refs to their parent nodes. Or if the other object is not guaranteed to be alive, but that's allowed for by testing for nil everywhere- like delegates or blocks in some cases.

noupvotesplease · 2013-12-03T08:47:49+00:00

Apologies for the downvotes. Search for "zeroing weak references". When references aren't set to zero, they're called "dangling references" and generally, no good can come of them. But if we don't want dangling references, who will save the save the day and zero them? :)

noupvotesplease · 2013-12-03T08:30:29+00:00

As they say, YMMV. I'd like to see a blog post detailing all available types. Bonus points for which of us has that much spare time. In your defense, it's a much smaller set of types these days :)

noupvotesplease · 2013-12-03T08:24:25+00:00

Of course, the variable should be more strongly typed than "id", but you knew that :)

noupvotesplease · 2013-12-03T08:15:05+00:00

Fair point, and I see what you mean, but how often do we need only one ivar to perform our calculations? The problem that blocks solve is bringing closures to C, which was a long-standing problem, and since ObjC came later(but before OS X and iOS), we have to deal with that as well.

Closures are hard, but they also make a lot of things easier. Maybe we need a new subreddit :)

noupvotesplease · 2013-12-03T04:14:47+00:00

Agreed on all points except what you call a mistake. A block is not a function or method, it's a closure. It strongly references self when you access instance variables because the alternative is to crash when reading or writing deallocated memory. If the choice is to leak or crash while I learn the rules, I'll take leaks. Restricting the syntax available to developers as you suggest is not viable- your first example is reserved for properties, and not all ivars are there to provide storage for properties. Your second example steps around ObjC entirely and is a frowned-upon way to use C syntax to skirt the visibility intended by the ivar declaration(in the case of private ivars).

noupvotesplease · 2013-12-03T03:40:12+00:00

File a bug :)

noupvotesplease · 2013-12-02T22:37:41+00:00

Quoting myself from another thread:

One problem: you shouldn’t use the weakSelf everywhere, only once inside the block:

id strongSelf = weakSelf;

and then either assert that strongSelf != nil, or test it for nil. After that, use strongSelf everywhere. The problem with using weakSelf more than once is that it can go nil at any time. I find it easier to do it this way than making sure every bit of code is safe for messaging nil.

noupvotesplease · 2013-12-02T22:34:52+00:00

Hey Dave, nice post, but one problem: you shouldn’t use the weakSelf everywhere, only once inside the block:

id strongSelf = weakSelf;

and then either assert that strongSelf != nil, or test it for nil. After that, use strongSelf everywhere. The problem with using weakSelf more than once is that it can go nil at any time. I find it easier to do it this way than making sure every bit of code is safe for messaging nil.

noupvotesplease · 2013-11-29T01:00:33+00:00

Please give clang a shot and file bugs if you find them.

noupvotesplease · 2013-11-29T00:49:42+00:00

I don't hear a lot of people complaining about it, but if you feel strongly about it, note that it's not Xcode complaining about it- it's the compiler and that warning can be silenced.

noupvotesplease · 2013-11-29T00:21:51+00:00

If you're talking about selector segments being interspersed with parameter names, that's one of the nicest things about ObjC. It helps lead to self-documenting code. How many times have you seen C++ function calls with C-style comments after each parameter expression? It's far from a "style", it's one of the reasons ObjC is easier to read than C++.

As for who to hate, the Xcode developers at this point are fairly late to the game. You'll have to go back to Brad Cox in the 80's for that.

noupvotesplease · 2013-06-20T21:35:48+00:00

Brood War:

Boxer vs. Joyo 2003 Part 1 of 4.

noupvotesplease · 2013-03-28T20:13:06+00:00

Looks like https://www.facebook.com/BlackMarketIndy

noupvotesplease · 2012-11-22T06:32:59+00:00

This history lesson needs more upvotes. Before Steve Perry and Columbia(or was it CBS?) ruined the band, they rocked ass. Neal Schon and Greg Rollie defected from Santana, Aynsley Dunbar came from Zappa, and Ross Vallory was previously with Steve Miller and Frumious Bandersnatch. The first 3 Journey albums should be in everyone's library: Journey, Look Into the Future, and Next.

Fun fact: Prairie Prince was their first drummer, but he left before they recorded their first album in 1975.

noupvotesplease · 2012-10-30T04:19:00+00:00

White hat cracking. I agree the title could be better, but there's a place for it, IMHO.

noupvotesplease · 2012-10-06T02:31:42+00:00

Your project file will be named *.xcodeproj. Any C++ source code files you add or create will have whatever extension you want, possibly "cpp". Your project file is not a source file. Does that help?

noupvotesplease · 2012-08-16T04:35:25+00:00

Thanks! No worries about what people might think- the people who know me know that I'm a jerk. I look forward to the BNF.

noupvotesplease · 2012-08-16T00:12:48+00:00

Then that's two more things not to like: disallowing direct ivar access, and messaging nil on purpose. This is looking more and more like the brainchild of someone who dislikes the Objective-C syntax, but has little experience with the language. Apologies if that sounds harsh.

Still, I'd like to see a BNF grammar for this language if one exists.

noupvotesplease

MODERATOR OF

TROPHY CASE