Re:API changes in Snow Leopard
by gcv on Friday August 28, 2009 @04:10PM
(#792187)
Fascinating; kill -9 is now the official way to terminate an application.
To support improved shutdown, your application needs to mark itself as “dirty” or “clean,” depending on whether it has unsaved changes and needs to do work before quitting, or can be terminated without further notice. When the system shuts down, clean applications are terminated (via SIGKILL) without further interaction.
Re:API changes in Snow Leopard
by 9oliYQjP on Friday August 28, 2009 @05:55PM
(#792365)
I'm not sure why you got down voted to 0 for asking a legitimate question. The block objects are part of Grand Central Dispatch. A programmer tags an isolated unit of work as a block. The OS then takes these blocks and schedules them into execution queues. While the compiler adds support for defining the blocks themselves, OS X 10.6 provides purpose to these blocks. Just like you can have a VM which supports threads on an OS that itself is not multi-threaded, the feature would be pretty useless if only the compiler were updated as it has been for 10.6
Re:API changes in Snow Leopard
by pohl on Friday August 28, 2009 @06:04PM
(#792382)
This is one reason why I like the old NeXT term "system software" in favor of "OS". (The former is all inclusive.)
Blocks are a language feature, and do need compiler support. The version of the compiler that you need to use them in GCD comes with v10.6 system software.
Re:API changes in Snow Leopard
by ben on Friday August 28, 2009 @04:45PM
(#792256)
The first thing I wanted to see as a Smalltalker was how much they've baked Blocks into the libraries. I know Cocoa has always had very long method names, but some of these names are wild:
- #enumerateObjectsUsingBlock: is #do:
- #objectsPassingTest: or #indexesOfObjectsPassingTest: are #select:
Re:API changes in Snow Leopard
by tolmasky on Friday August 28, 2009 @08:40PM
(#792577)
The names make perfect sense within the context of the language. Just because you add a new feature to a language doesn't mean you should arbitrarily adopt the naming conventions of its implementation in another language.
Re:API changes in Snow Leopard
by antonovka on Friday August 28, 2009 @05:23PM
(#792315)
The names are silly, and Apple isn't leveraging blocks nearly as much as they could be. The very first thing I did is add an option monad, plus additional collection methods (including the nice and short map and filter) via categories.
My only complaint is that The [[]] messaging syntax gets way too verbose when chaining together sequence comprehensions.
Re:API changes in Snow Leopard
by albertcardona on Saturday August 29, 2009 @05:49AM
(#793021)
I call it "ctrl+space semantically-aware word completion" and "self-documenting function names."
Nothing unusual in multi-year multi-programmer software.
As much as I like succinct function names, in my experience they don't work when there's more than one hacker involved. A strategy I have followed is to make long names for the top-level, interface-like functions, and succinct ones for all the internals; i.e. put the verbosity where others need to look up code to use it as a library, where "library" is understood as an individual/indepenent component of a larger software project.
Re:API changes in Snow Leopard
by alexk7 on Friday August 28, 2009 @03:37PM
(#792100)
I don't know if someone else care, but I find it annoying that the "blocks" proprietary extension to C/C++ is conflicting with C++/CLI syntax for managed pointers.
To support improved shutdown, your application needs to mark itself as “dirty” or “clean,” depending on whether it has unsaved changes and needs to do work before quitting, or can be terminated without further notice. When the system shuts down, clean applications are terminated (via SIGKILL) without further interaction.
Huh? Isn't this a feature of a compiler, not an OS?
So blocks need to be supported at the compiler level, in the Objective-C runtime and in OS-wide processes (which would be Grand Central itself).
Blocks are a language feature, and do need compiler support. The version of the compiler that you need to use them in GCD comes with v10.6 system software.
http://code.google.com/p/plblocks/
- #enumerateObjectsUsingBlock: is #do:
- #objectsPassingTest: or #indexesOfObjectsPassingTest: are #select:
And so on. Here's what I'm looking at:
http://developer.apple.com/mac/library/documentation/Cocoa/R...
My only complaint is that The [[]] messaging syntax gets way too verbose when chaining together sequence comprehensions.
Nothing unusual in multi-year multi-programmer software.
As much as I like succinct function names, in my experience they don't work when there's more than one hacker involved. A strategy I have followed is to make long names for the top-level, interface-like functions, and succinct ones for all the internals; i.e. put the verbosity where others need to look up code to use it as a library, where "library" is understood as an individual/indepenent component of a larger software project.
Worst thing that could happen would be a slight conflict in the brain of people coding simultaneously in Objective-C and in Managed C++.
OpenCL was originally developed by Apple and then formalized by the Khronos Working Group.
So, it kind of depends on your definition of proprietary.
("citation needed", I haven't checked this)