Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: C++ important on Apple too (Score 3, Informative) 193

There's not a lot of reason to pick up Objective C unless you plan on targeting Apple.

C++ is also important when targeting Apple. Objective-C is the language of the Cocoa API (Mac OS X and iOS), however there is no need to use it beyond code that makes Cocoa based system calls. And getting C++ and Objective-C code to call each other is trivial.

Personally I recommend separating UI and platform (OS) specific code from an app's core functionality and implementing the UI/platform-specific code in whatever the native language for the platform is and implementing the core code in C/C++. This leaves the core code portable, ready to target other platforms. I have iOS apps where the core code can be compiled in a console Linux environment and exercised by various scripts (regression testing) and in a random manner (fuzzing).

Comment: You can distribute source ... (Score 2) 115

by perpenso (#49168185) Attached to: Unreal Engine 4 Is Now Free

IANAL, but it looks like distributing the source code to "end users" of a compiled program is not allowed

Untrue. I am also not a lawyer and I only skimmed the agreement so perhaps I am misunderstanding it but I believe you can distribute the source code to your game.

What you cannot distribute is Epic's game engine source code and binary tools. However your customer can download these at no charge from Epic just like you did. So it seems a customer can get everything they need to rebuild the game themselves. They just need to download game code from you and engine code/tools from Epic.

Comment: Useful if it gets people thinking disaster prep (Score 1) 219

Zombies don't need to be realistic, merely being entertaining is sufficient. They can be quite useful to bring up the topic of disaster preparedness. A super-flu, ebola, etc is not necessary for crisis. A "mundane" storm or earthquake that knocks out the power to millions and shuts down the supermarkets is sufficient. Anything that might spark a conversation or some thought about having a weeks worth of unrefrigerated food and water at home is a good idea. OK some plastic trash bags, baby wipes, and purell might also be a good idea for your in-home campout.

Similar story for those survivalist/prepper shows.

Comment: Re:Best idea is not to hide. (Score 1) 219

One smart human with 30 minutes to prepare makes a spear and scares off a lion, wolf, or even a bear.

Maybe in the movies. In reality a solo human is almost certainly at the mercy of the bear once things get to spear range. If you survive its because the bear was motivated by dominance / threat removal not predation. Wolves, you won't be against one, and while one gets your attention another will dash in and out for a quick bite to the leg to get you bleeding, to start the process where you become too weak to fight. Lions, well in North America that will be the mountain lion that you never saw and never raised your spear against.

Why? Because we are some sneaky, devious, son's of bitches that outwit enemies.

Not really. The most important factor is the social factor, the extended family / tribal behavior. Solo sneaky toolmaker -- highly vulnerable. Tribal sneaky toolmakers -- very dangerous.

Comment: Re: Right, but does it correctly model... (Score 1) 219

Highly vulnerable to fires. Without maintenance (ex: gas company crews fixing leaks -- happens all the time every day) and firefighting you are at risk and still need to be ready to bug out and be mobile. Think of the fires that followed the 1906 San Francisco earthquake.

Comment: Re:Someone building iOS on x86 ... (Score 1) 88

, this isn't something surprising nor some secretive thing. You do realize that the iOS simulator runs x86(_64) compiled code, right? That's how it's always worked.

Yeah, I realized this just as I typed the word "simulated" in another post. :-)

However I still expect that much iOS specific code is run in regression tests completely separate from the various device simulators.

But then I'm biased. Giving all the porting I've done I'm a little "enthusiastic" about separating core code from UI code and other platform specific code. Windows apps, Mac OS apps, iOS apps, Android apps, etc ... I've tended to have core code runnable in a console environment for testing on the headless Linux box in the closet. Regression, fuzzing, etc.

Comment: Mac OS X based iOS device simulators (Score 1) 88

I'm referring to much more than Darwin. Possibly iOS in its entirety. At a minimum various iOS specific frameworks in a regression test environment. Including some hardware specific frameworks where inputs are simulated.

Wait, speaking of "simulated", we have the Mac OS X based iOS device simulators used during development. Doh!

{ Oops, forgot to log in, didn't mean to post AC }

Comment: Can scale back fossil fuel based generation ... (Score 2) 150

by perpenso (#49165919) Attached to: World's First Lagoon Power Plants Unveiled In UK

While tides are predictable that are also predictably different than electricity demand curves. Storage is still needed to shift production to meet demand. Predictability is not dispatchability. Add the cost of storage need to shift production to demand and the cost is much higher.

Its not that simple. Tidal generation can also be used to temporarily reduce fossil fuel based generation. Throttle down the fossil fuel based plants during tidal generation, it predictable and schedule-able after all. Power generation can remain constant yet less fossil fuels are used.

Comment: Someone building iOS on x86 ... (Score 3, Insightful) 88

It just takes a dev or two building and testing the code on x86 just to make sure its cross platform.

Such an effort can pay for itself simply through the bugs it will find. What is a very subtle and sometimes currently unnoticed bug on one platform may become a highly visible bug on another platform. Bugs sometimes manifest differently on different platforms. I've been on several teams over time where we moved good "working" code to a new platform and watched it crash spectacularly over and over again. Each time the original devs who thought their code was in great shape were shaking their heads wonder how it ever ran on the original platform. Lucky values in uninitialized variables and such.

So yes, someone is probably building and testing iOS on x86 but it has little to nothing to do with any plans regarding using x86 on any devices. Sort of similar to the Microsoft's efforts to internally build and test Windows on a non-x86 platform after it gave up on shipping MIPS, PowerPC and Alpha binaries. Its more about testing and future proofing a core asset than any short term plans.

And if I were running Intel I would be supplying the engineers to do so if Apple was not doing it on their own initiative.

Comment: Mildly annoyed ... (Score 1) 191

by perpenso (#49164763) Attached to: That U2 Apple Stunt Wasn't the Disaster You Might Think It Was
I remember the world being surprised to mildly annoyed at best, surprised in the "did they (Apple) really do that, seems rude not to ask" sense. Very annoyed was definitely a minority. And of course those thinking it rude and those mildly annoyed included folks who had purchased U2 albums in the past, including the distant past. Those not interested at all seemed to delete it and calmly share sentiments such as "I hope Apple doesn't make a habit of this", a bit short of very annoyed.

So no, its not surprising that a lot of people listened to the album once they found it on their device, despite its "rude" delivery.

Comment: Re:It was a terrible example of went to use a goto (Score 1) 677

by perpenso (#49075139) Attached to: Empirical Study On How C Devs Use Goto In Practice Says "Not Harmful"
Note that Torvalds concedes that the specific code example being complained about does not benefit by the use of goto.

Also not brought up in that discussions is that where to draw the line between goto and nesting depends on the amount of nesting and the length of the code in question, not nesting alone. People using goto in shorter simpler code are making the code less readable.

Now Love's example is a great one because of the falling through from one undo to another. Because the bailout applies to all nesting levels so far not just the current level. That would be awkward in purely structured code. However if the undo were constrained to only the err'ing level, if there had been a goto out after undo C and undo B then structured if/else would have been more readable. But as is with multiple levels of undo it is s very appropriate use of goto.

Unfortunately much use of goto is done when the code is simple and short, unlike Love's example.

What good is a ticket to the good life, if you can't find the entrance?