|
Saturday, April 27, 2002 |
|
Kevin Altis mentioned the use of Python in commercial games. That reminded me of the port of Python to PS2 and, digging a bit deeper, revealed that the port's sponsor (Kalisto) is working on SpongeBob SquarePants, which will use Python and Python based tools during development.
As a matter of fact, Jason Asbahr will be speaking on the subject at the upcoming O'Reilly Open Source Convention. |
|
I have one misbehaving pixel on my new [replacement] TiBook. It is in the lower left portion of the screen. It seems that the blue channel is stuck on. What is truly odd is that it isn't completely stuck! Vibration will cause it to flicker and sometimes go away entirely. However, the most bizarre behavior is that the pixel flickers with drive access. It is as if the blue channel of that particular pixel is a drive activity light.
Given Aqua's predilection for all things blue, having a single pixel with the blue channel always on is about as innocuous as it gets. |
|
This is a response to a message posted to the cocoa-dev mailing list. It contains a bunch of URLs that I need to remember across new environments and, as such, I thought I'd blast it into Radio so it goes on my "permanent record"
Heh... I would imagine that whole 'other 95%' thing might has something to do with it, as well. Having been a long time NeXT developer, the Macintosh software market seems positively huge in comparison. Kind of like the difference between potential Windows customers and potential Macintosh customers.
(I stuck with NeXT and, now, OS X because-- frankly-- sitting in front of a Windows box makes me nauseous in fairly short order. I would have to replace far too many keyboards to even ship a single app.)
Microsoft's documentation and their developer program is certainly impressive in both the sheer volume of materials they ship you and the quality of a lot of the documentation. My experience over the last 20 years of development work has been a bit different. Microsoft provides excellent documentation, Apple provided excellent docs up until the introduction of Carbon, Rhapsody and the precursors to OS X.
In the early days, NeXT provided excellent documentation, as well. Not only did you have reams of straight reference materials, but NeXT provided excellent concept and architecture documentation.
As OS X has evolved, the documentation has improved immensely. These days, finding the appropriate documentation is more of a challenge than anything else. There is actually a fairly good reason why the docs have been lagging for some time and are just now starting to catch up (not that I'm attempting to make excuses for the state of the docs, simply that I can understand and even sympathize with the state they are in).
Namely, the Cocoa, Carbon, and WebObjects SDKs had been moving sideways until relatively recently. Cocoa is fairly solid these days, but Carbon and WebObjects is changing and evolving in fairly significant ways. Because of this, any documentation written against these APIs often must be massively revised with any major release.
Given the nature of the documentation-- highly technical documentation that requires heavy engineering involvement to produce-- it consumes a tremendous amount of engineering effort to keep everything up to date. Unfortunately, engineering resources are not cheap and time is not plentiful. I can understand (but don't necessarily like) that Apple would make the decision to let the documentation slip a bit until it stops moving sideways.
This is exactly what appears to be happening. The Cocoa APIs are solid-- there have been additions, but no major architectural revisions recently. As of the April development tools seed, executing the command....
find /System/Library/Frameworks -name '*.html' -exec grep -l 'forthcoming' {} ;
...reveals that there is not a single 'description forthcoming' left in the documentation for any of the Cocoa related frameworks. Likewise, as of WebObjects 5.1 [update whatever], the WO documentation has been moved forward to a similar state.
Core and Carbon-- less so Carbon than Core-- still has a number of 'description forthcoming' bits throughout the docs, but both of those APIs are still evolving.
On the non-reference front, there is quit a lot of examples and taks/concepts guides available. Again, the challenge is largely one of finding them.
---
For Cocoa:
Excellent starting points for figuring out where all the useful Cocoa documentation lives. The second document is particularly useful to those new to the Cocoa development platform. Scan through the last document to gain an understanding of some of the vocabulary used throughout the rest of the documentation.
This is the book to read to gain a relatively deep understanding of Objective-C. However, it is also of value to programmers of other OO languages as it provides an awesome overview of OO architecture and implementation methodologies. This is a very mature document; I believe one of the first version shipped with, at least, NeXTSTEP 1.0-- maybe earlier-- in 1990. However, it is not obsolete/out of date!
The first link leads to the Apple Developer Connection site-- likely not news to anyone here-- from which you can access any number of very useful resources. If you haven't done so, register for a free ADC account as that will give you access to various software seed (though not as many as the $500/year select membership) and give you the ability to file bug reports and feature requests via the third URL. (And do file bug reports / feature requests. As long as your report or request is clearly written and contains the appropriate information-- version # of the system, build # of the PBX tool suite-- Apple really does read the things and really will fix the problems or add the feature (if it makes sense to do so, obviously).
The gateway to all of Apple's mailing lists. Well, not all, but to a vast majority of the lists that are pertinent to developers. Obviously, you have already subscribed to cocoa-dev, but there may be some other lists that are of interest. If you aren't sure whether or not a list is useful to you, subscribe in Digest mode. This will limit the
The Omni Group (awesome company -- buy their stuff! -- they offer the mailing lists completely voluntarily and, beyond the @omnigroup.com, in each post, I have never seen Omni use the lists for marketing purposes) also has a number of mailing lists of interest to developers. The Omni lists tend to have more traffic and, for whatever reason, tend to have a bit more rampant advocacy then the Apple Lists. Digest mode is definitely the way to go on these lists as macosx-dev alone often has well over 100 messages posted per day (many more, in some case). WebObjects-dev is likewise-- I have seen digests with up to 120 messages in it.
The first three links all lead to a boatload of information about Cocoa and OS X development (and OS X development, in general). The last link leads to a page full of links to man0y other sites.
Apple offers a bunch of excellent Cocoa training. Big Nerd Ranch offers excellent Cocoa training, as well, and I hear that their training facilities is quite cool. Aaron-- the primary dude behind BNR-- has been doing Cocoa and Cocoa related training for a long, long time.
Finally, there are some excellent books out there for Cocoa development. Aaron Hillegas' "Cocoa Programming for Mac OS X" is available now and does a wonderful job of teaching the developer how to write real world Cocoa apps in an effective manner. On the horizon, Simson Garfinkel and Mike Mahoney have rewritten what was the definitive how to program NeXTSTEP book in the early 90s. The new version is title "Building Cocoa Applications : A Step by Step Guide" is quite excellent.
Of the two, I would actually recommend picking up both. I had the opportunity to act as technical editor on both books and, as such, had a close look at the content. They are really two very different books; the Hillegas book tends to focus on higher level APIs and architectures while the Garfinkel/Mahoney book is oriented more to building a complete application that exercises everything from the unix command line through to high level features. The two books complement each other extremely well.
---
For WebObjects:
Combining the last software updater update of WO 5.1 with the recent update of the JDK, Apple now ships relatively complete reference documentation with WebObjects. It is hard to find because-- unlike Cocoa, Carbon and the Core-- there isn't an index into the documentation available from within PBX (that I have discovered).
I have found three quite workable solutions:
- configure JavaBrowser correctly and it will display javadoc style docs inline as it does the classes. Out of the box, JavaBrowser is nearly useless. I wrote a shell script that will rewrite all of the path preferences for JavaBrowser such that the next time JB is launched it'll basically have every class and piece of documentation either shipped with the system or installed in the standard extensions directory. The second link leads to a page that describes the script and provides a link for downloads.
- LaunchBar (can be had via the third URL). With LaunchBar installed and correctly configured, I can type (cmd)-(space)WOTF(cr) and LaunchBar will open the WOTextField.html documentation. Very useful.
- If you happen to have a decent Internet connection, searching the documentation is as easy as plugging the class name into the field at the top right of the fourth URL's page. If someone were motivated, it would be trivial to rip out that form such that you had a minimal version of it on the local hard drive, thus saving the initial round trip to load a page where 95% of the content has nothing to do with the desired search.
Of course, all of this has pertinence to Cocoa development to varying degrees.
The OmniGroup hosts the quintessential development mailing lists related to WebObjects. webobjects-dev and the eof developers mailing list are likely the two most relevant lists. Apple has an announce list, but that's it. There is also a 'WebObjects-newbies' list hosted at yahoo-- as its name implies, the questions tend to be more novice in nature.
---
For Carbon / Core:
Basically, Carbon/Core documentation can be found from the same general locations as the WebObjects and Cocoa documentations and resources. The one big difference with Carbon/Core is that the header files often provide a lot of additional information about the APIs that haven't made it into the documentation. Unfortunate but, as mentioned earlier, the APIs are still somewhat in flux which greatly impedes the creation of documentation.
The Core differs from Cocoa/WebObjects in that the source for parts of the Core is available within the Darwin CVS repository. Follow the instructions at the first URL to obtain the source.
(Assuming you did find all the docs mentioned above along with the concepts guides, etc...)
It sounds like you might be looking for something that isn't there. When learning Cocoa, developers with a lot of deep experience using any of the myriad of APIs available for application construction are actually at a disadvantage until the epiphany happens.
In particular, +the Cocoa Epiphany+ is the moment when the developer realizes that, yes, in fact, the Cocoa frameworks really will do all the work for you.
One key difference with Cocoa development over a lot of other GUI toolkits is that the developer's code is written in a more passive context.
In Carbon (more old style than new, but the new style stuff is still really hairy to set up), you typically have to write your own event loop and take care of all of the event dispatching within that loop-- even for functionality (such as the functionality associated with a Quit or Hide menu item).
With Cocoa, the only event handling code you ever write is for features that deviate from 'standard application behavior'. Have a look at the TextEdit source for a decent (though there is some cruft that could go away) example of this; fonts, rulers, cut/copy/paste, text selection, text editing, multiple document management, save as/to, revert, printing, hiding, services, spelling, speech, open recent, a basic about panel, handling of graphics in editable text, etc. are all given to you by the AppKit. There is very little custom code in TE and what is there is basically only the code necessary to make the AppKit behave like a text editor.
Another key to success: Don't pick a fight with the APIs. It is generally unnecessary and you will lose. If something seems like it is a whole heck of a lot harder than it "should" be, it is extremely likely that you are attempting to make the APIs behave in a fashion that is not natural to their architecture. Step back, read some docs, do some googleresearch, and re-approach the problem. A large part of the time, you'll discover that there is a much better way to solve the problem at hand without writing tons and tons and tons of code.
Rephrase the question: How long until all of the software that sells mac systems-- Office, PhotShop, Illustrator, etc.etc.etc.-- no longer has any dependencies or ties to Carbon?
Until that happens, Carbon is here to stay.
Most of the examples on Apple's site are still in CodeWarrior because even porting them straight to PBX requires more work than is warranted. Most of the sample code presented as CW projects would need to be rewritten to properly exemplify whatever APIs they are supposed to demonstrate.
This is another case where the samples will improve in quality over time as the APIs stop moving sideways and start moving forward.
In any case, there is a lot of very useful functionality in Carbon and Core. It is easily accessed from Cocoa. Almost all of the recent 'train hacks' (I write little apps on the commute to/from the office) have a handful of calls into Carbon/Core to take advantage of APIs that don't yet have an ObjC wrapper.
Which brings us to the next point....
QuickTime is a cross platform API/implementation and, as such, it needs to have an API that is easily integrated into many different development platforms. An ANSI-C compliant procedural API is about as cross-platform as you can get.
However, don't let this stop you from using QuickTime in Cocoa applications. Cocoa provides an NSMovieView and NSMovie class. These classes are simple wrappers around the display of a QT movie and a QT movie itself. The NSMovie object implements the method -QTMovie that returns an opaque pointer to the QuickTime movie encapsulated within the object. With this pointer, you can manipulate the movie's contents via the standard QuickTime framework's API.
Again, this is a case of APIs that are still shifting a bit impeding certain other solutions from coming to fruition. As well, wrapping a complex, general purpose, procedural API with a set of ObjC classes that intelligently provide access to that functionality in a general purpose fashion is actually very hard.
Even once done, maintaining the OO wrappers can be costly in that the wrappers have to be modified to track any changes made in the underlying procedural APIs. Certainly, this is also an issue when you have built your own specific purpose wrapper, but to a much lesser degree in that your specific case solution doesn't exercise the entire underlying API and is not trying to express all functionality possible.
However, it is trivial to hide the procedural calls behind opaque data types and a decent set of classes to wrap the APIs in the fashion you need.
It is likely that Apple will make an ObjC accessible version of the QT APIs available someday. Until that happens, don't let the lack of it stop you from using Cocoa / OS X!
That's the key; Apple is still migrating to OS X. There are still chunks of API and functionality that need to moved across. Even with the rock solid (I haven't had a machine crash in months), totally kick butt, 10.1 release we have in our hands now, it is-- by no means-- a complete migration!
WWDC should be very interesting this year as I believe we are going to see huge strides on the migration front. Overall, the OS "feels" like most of the core issues-- stability, performance, etc-- have been addressed to the point where Apple is focusing a lot of effort on new development.
Keep in mind, as well, that Apple has "bet the farm" on Cocoa (and WebObjects)! iPhoto is a Cocoa-only application; it doesn't even run on OS 9. As well, most of the applications that ship with the operating system are written primarily against Cocoa with the few odd calls into Carbon/Core/Hidden APIs. The one notable exception is the Finder. Unfortunate in that the Finder still has some fairly serious usability issues about it.
If anyone has any ideas or suggestions for me, I would love to hear them and
am very excited about being a new member of the Mac community!
Hopefully there'll be one or two nuggets above that you haven't stumbled across elsewhere...
b.bum
Wake up. Breathe....
.... keep breathing. |
|
Any third parties out there have any decent Radio templates they'd care to share. I would like to have more links to other sites and have working stories, but don't have the time to go there... 3:48:51 AM 
|
|
This should be a story, but stories in Radio are a pain in the butt. If someone can give me a macro that can generate a viable link to a story on both my desktop and the published pages, I might go there... Kevin Altis has returned to the Mac platform. He has spent the last 5+ years with a Windows desktop. Kevin and I worked together long ago on the Mac platform. We did a couple of Hypercard based products. At some point, our paths diverged-- Kevin went Windows and pursued [successfully] an internet related venture while I moved to the NeXT platform and continued a focus on programming. Frankly, during the mid-'90s the Mac wasn't really a player in the Internet development market (certainly, the Mac was and still is a major player on the creative/content side) as the platform simply didn't support the 'standards' that became ubiquitous during that period of time. Given Kevin's focus on cross platform software development tools in the form of Python, wx* and wxPython, moving to OS X from Windows has become a viable and, hopefully, attractive option. However, the point of this post is not to launch into some far reaching rant about various operating systems and such. The point of this post is to give Kevin (and anyone else who cares) some decent starting points for setting up an effective development environment with OS X.
Some Basic Mantras to Repeat OftenMantra: Don't fight the system. If something seems stupid or arbitrarily hard to do, you are likely doing it wrong. Take a step back, read the docs, research the problem via Google, ask the appropriate group of experts, or simply sleep on it and try again. Mantra: OS X is not OS 9. OS X has about a zillion more moving parts than OS 9. Most of this is not because OS X is bloated, but because it supports a tremendous number of standards out of the box. OS 9 was designed to be a standalone machine that had various network interoperability features tacked on (brilliantly so in the '80s-- AppleTalk nets were trivial and cheap to set up while the rest of the industry was still in the '1200 baud modem is good enough for me' mindset). OS X is designed to be on the net 24/7 -- it is designed to behave well and play safely on the relatively mean playground that is the Internet. However, OS X doesn't have to have a network connection to work (unlike Win XP's habit of requiring the occasional communication with the mothership). Mantra: OS X is built on a Unix foundation on top of a Mach kernel, but that doesn't mean you have to be even remotely proficient at the command line to be a power user or, even, a highly effective developer. A lot of users out there will never see the command line because they never need it-- the fact that Unix is under the hood doesn't directly affect their day to day lives. But it does affect the quality of user experience. Example: When you turn on 'web sharing', a very nicely configured, industry standard, incredibly popular, Apache web server is started. Mantra: OS X is not OS 9, part II. If you come from a long history of using Mac OS 9 and prior, assume that the way you used to do things may no longer be the best way to do things. This also goes back to the first mantra-- don't try to bully the system into behaving like something that it isn't! There are good and bad aspects of this. Good: you don't need to quit applications to do something else. OS X will take care of paging out applications that haven't been used in a while. They page in faster than they launch. There are a couple of exceptions in the form of mostly Carbon apps that don't idle properly. Microsoft Word is an excellent example with a workaround (turn off live word count and it stops "idling" at 50% CPU). Bad: certain handy features are either gone or haven't been implemented yet-- spring loaded folders is a good example. Mantra: When writing code, don't fight the APIs. If a task seems like ti should be relatively easy to do, but you find yourself writing a big pile of code, it is very likely that you are misusing the APIs. In the context of Cocoa, if you find yourself trying to customize the heck out of some object's behavior, something is amiss.
Getting StartedThe assumption is that you are starting with a box that has been freshly uncrated and has a clean install of OS X on it.
MemoryThe minimum amount of memory I have in any of my OS X machines (including machines for family members that are relatively non-technical computer users) is 512MB of RAM. If possible, I generally try to shove 768MB into the machine. This isn't because OS X is a memory hog. There are parts of the operating system that are certainly memory hogs, but that is the price one pays for the fancy look and feel. I put as much memory as possible under OS X because OS X will use every last bit of memory to make the system run faster. Have you ever noticed that opening applications or documents after they have already been opened once is typically many times faster? The reason why is that OS X uses any memory that isn't being used for a running application as a disk buffer. Under Mach, files are mapped into memory. What that really means is that the bytes on disk are read into memory-- as needed and only as needed-- and stay there until one of two things happen; the system needs more memory for other purposes or the file changes on disk. Even if you never use more than, say, 350MB of RAM, a machine with 1GB of ram will perform better over time than a machine with 512MB. As well, the slower the hard drive, the more apparent the speedup. Laptop drives are typically very slow-- 4200 RPM w/slow seek times. If you load your laptop up with lots of memory, all that extra memory is going to be used as a disk buffer and will significantly reduce the amount of Disk I/O over time. You win.
First BootThe first thing to do is to run the software updater repeatedly until it tells you that your system is up to date (for a 10.1.2 system, that seems to be 3 times with 3 reboots-- unfortunately, Apple borrowed the 'reboot after installing anything' philosophy from Windows). If you need some random localization package for some language not shipped on the CD, make sure you install it when your system is loaded with 10.1.3. Installing localization packages on 10.1.4 is currently broken. Oops. Upon setting up a new machine, I usually don't even bother to boot from the hard drive even if the machine is new-in-box from the Apple Store. Just boot off of the CD and run through the installation -- this will be a required step if you need to partition the drive. The installation process is easy and doesn't take terribly long.
What about partitioning? Frankly, I have never bothered beyond separating my operating systems (OS X and OS 9 installed in the same partition, if OS 9 is installed at all-- since Apple added support for PCMCIA memory stick readers and Office X was released, I often don't even have Classic installed) into separate partitions. I do go through the trouble of creating a separate partition for user accounts and other data. If you do decide that you want to partition your drive, make sure you allocate approximately 10GB for the OS X system volume. This will give you plenty of headroom for the swapfiles (up to 4GB), core files (which can be useful), and a /tmp/ that is of a reasonable enough size to use as a scratch area (on my system, PBX builds everything to /tmp/ for a variety of reasons). Some people swear by pushing the swap files off into their own partition. There are even some tools that make it relatively painless. If you do go this route, make sure you allocate a 4GB partition to the swap space. OS X is very efficient about pushing stuff to swap thanks to the Mach kernel and, as such, there will be the rare situation where the system is using several gigs of swap, but is still perfectly responsive. There is no need to starve the VM subsystem unnecessarily. Personally, I have never bothered. Virtual memory is so many orders of magnitude slower than physical memory that anytime the machine is paging to/from disk for whatever reason, +/-30% performance just doesn't matter! If your machine is paging, it will be abundantly obvious. Get more memory. Avoiding use of virtual memory is critical on a laptop. The drives are so slow that the machine basically just stops for a bit when paging. (There isn't much the kernel can do to avoid the pause-- paging is a very low level and intrusive operation). This Google search has both interesting technical explanations and howtos.
First pass at User ConfigurationOK-- machine has booted, the software is all up to date, and you are logged in and ready to go. Before I install the developer tools or do anything else, I will grab a handful of applications that make the rest of the installation process a lot less tedious and make the general usage of OS X a whole lot more pleasant. Before you download and install any apps, think carefully about where you want to install them. Into the default Applications directory? Probably not-- why clutter something that the system really owns and why put yourself in a situation where replacing the operating system requires re-installing a bunch of apps that could have been avoided? I create an Applications directory within my Home directory. The Finder and the rest of the system treats this directory in the same fashion as /Applications in that extensions and services will work as expected. This has the advantage of keeping your working environment isolated from the system and makes moving from machine to machine easier. OS X is always a multiuser system, even when there is only one user that ever uses the machine!! Treat it as such-- see a previous rant on the subject. When installing applications, if the application has an installer program that does anything more than copy the application to a location of your choosing, there better had be a damned good reason why! On OS X, the right way to install things is to ship your app on a disk image and have the user drag and drop the app (or apps) to wherever they want-- in this case, into ~/Applications (~ means "current user's home directory"). Microsoft got this with Office as far back as Office '98 for the Mac. Furthermore, if an installer insists on quitting other applicatinos, you know you are in trouble. In most cases, if an OS X enabled app ships as something other than a drag-n-drop install, it is a fairly good sign that the developers of the app haven't really grokked the whole OS X experience yet (There are exceptions, of course, but I'm hard pressed to name 'em -- obviously, stuff that installs kernel drivers generally wants to wrap things into a pretty installer so the user doesn't have to install multiple bits all over the place).
The First Apps To InstallThe first thing to do is to bring up Internet Explorer and download a web browser to replace it with. Unfortunately, IE sucks. It is slow, buggy, and has a tendency to stop responding to events for long periods of times while it sorts things out. My two favorite browsers, at the moment, are OmniWeb and Chimera. Both do a great job of rendering HTML. Omni can be a bit slow and eats tons of memory (as it caches stuff in memory, but takes good advantage of the virtual memory model on OS X), but renders just about everything just fine-- including sites that IE on OSX can't deal with. OmniWeb is an extremely polished app and has some tremendously cool features tucked away-- explore the preferences thoroughly!!! Chimera is a very early alpha browser based on Fizalla (mozilla) and is blazingly fast and surprisingly stable/usable for this early in development. New builds come out regularly and-- as with any well engineered Cocoa project-- progress has been extremely rapid. Definitely worth checking out. At this point, I probably use OmniWeb about 80% of the time and Chimera about 20% of the time. There are some other browsers for OS X; iCab is a very nice browser and has some cool HTML developer oriented features. However, my experience with iCab is that it "feels" like a Classic app that was ported to Carbon without fully optimizing event handling for OS X. It has a tendency to stop responding to events or to perform in an extremely choppy fashion during page loads. So-- now that you have a real browser or three installed in ~/Applications, what else do you need? LaunchBar is as close to the perfect application as any I have encountered. From their web page: LaunchBar provides lightning fast access to thousands of files, web-bookmarks, email-addresses and applications just by entering short abbreviations. Type OW to launch OmniWeb, AHN to open the "Apple Hot News" web page, BM to write an email to "Bob Miller" or HP01 to locate a folder named "Holiday Pictures 2001". The set of items and their corresponding abbreviations don't need to be configured manually. LaunchBar uses a very powerful, adaptive abbreviation search algorithm that allows you to enter any thinkable abbreviation of the searched item. An understatement. Basically, LaunchBar effectively-- i.e. in a fashion that is easy to learn and feels natural-- eliminates using the dock as a means of switching between or launching applications. But that's not all; it does the same for everything from bookmarks to developer documentation to source files to anything else you happen to have in the filesystem. Configure LaunchBar to launch when you log in. I didn't move to using LaunchBar on OS X until well after my brain was wired to go to the Dock for applications. There is an easy fix for that-- make the dock completely unusable and force yourself to use LaunchBar for a week. You'll never go back. To break the dock: turn off magnification first. Then, go to the command line and invoke:
The second line kills the dock. When it restarts, the icons will attempt to render uselessly small. To fix, go to the Dock Preferences and adjust the Dock Size. Make sure LaunchBar is already running when you do this. Give it a week...
The Dev ToolsNow that you have a decent browser around and can navigate between apps with lightning speed thanks to LaunchBar, it is time to install the developer tools. First, if you haven't already done so, create an ADC (Apple Developer Connection) account-- the free one will do just fine. The ADC account is extremely valuable for two key reasons; first, it gives you a conduit via which you can report bugs and request features. Apple really does pay attention as long as you provide thorough reports that include the build number of the operating system and, if pertinent, the developer tools -- I have reported over 250 bugs and/or feature requests since OS X shipped and many have been fixed or new features implemented. Don't expect a lot of feedback, but every single report does get read and will be addressed eventually. This is also the means via which the user and developer community can influence the future directions of OS X. Second, an ADC account-- even the free one-- will give you access to the various seeds and SDKs that may be of interest. Currently the free ADC account provides access to the WebObjects development package. A select membership-- $500/annually, I believe-- gains you access to several other seeds, including the April beta seed of the new development tools (new PBX, GCC 3.x, etc.etc... no, I'm not breaking NDA-- Apple invited public discussion recently on a public mailing list). With ADC account in hand, determine if there is a later version of the development tools available from Apple in comparison to the ones that shipped with your machine. Grab the latest. Install the Developer package. It is straightforward and relatively painless, but will take awhile. Install the WebObjects developer package, if so desired. Highly recommended if you are going to be working with Java as the WebObjects SDK includes a bunch of Java resources that are quite useful in non-WO development contexts.
Now what?Regardless of whether or not you have every worked with Unix for any length of time, you should definitely explore the command line. Sure, the UI isn't great (though some would argue otherwise in that most commands do come with pretty decent documentation in the form of man pages), but there is tremendous power to be had at the command line. (Example: I use ImageMagick all the time to convert images from one format to another or to do simple imaging operations. The command 'convert SomeImage.tiff SomeImage.jpeg' is a heck of a lot faster than launching an application and doing the same operation from the GUI.) For true command line nirvana, the best way to go is to install Fink. Don't bother with the OpenOSX or MacGIMP CDs-- they are merely prepackaged binaries of the software built using Fink. It is pretty much guaranteed to be outdated upon delivery and Fink does a wonderful job of keeping itself up to date in a fairly automated fashion. An alternative to Fink is The GNU Darwin Distribution. However, the documentation pales in comparison to Fink. As well, Fink has a much better package management system and deals with dependencies extremely well. By default, fink installs into /sw/. A slightly odd place, yes, but leave it there and forget about it. Just follow the instructions on setting up the shell's environment variables. Do not install Fink to /usr/local/. It can be done and I have done so in the past, but it will cause headaches down the road. Notably, if you install Fink to /sw/, then /usr/local/ is free to be used for anything that needs to be hand compiled -- very handy considering that numerous source packages If you are going to be doing any 'bleeding edge' work with various command line tools-- like, say, with Python and wx*-- then you'll want to reconfigure Fink to download and install the 'unstable' packages. Unstable does not mean 'will likely crash early and often'. In the context of Fink, unstable means 'the package works, but hasn't been qualified by enough users for us to be comfortable pushing it into the stable tree'.
A slight divergence: root, administrator, and user privilegesFirst and foremost, do not ever log into your machine via the loginpanel as root! There is simply no need and there is way too much potential for seriously screwing things up. Similarly, all security features of OS X are effectively out the window; file permissions don't matter and any application can write something to the wrong place in the wrong way and completely hose your system. Even from the command line, there is rarely a need to actually log in as root even when performing relatively low level system administration tasks. Example: I consider myself to have a decent understanding of the inner workings of OS X and am not afraid to customize things like the boot sequence, sendmail, etc. Yet, the record of logins on my machine shows that I have never logged into the machine directly as root. Not once. Under OS X, root is definitely available, but there is also the concept of Administrator. Administrator has most of the privileges as root, but isn't actually a user. Instead, the administrator is a separate group of which your default user account will be a member. You'll see this pop up throughout OSX -- when you make certain preferences changes, the system will ask for an administrator username/password pair. Even if the user you are logged in as doesn't have Administrator capabilities, another user who does can type their username/password to give that user temporary administrative rights to a particular program or bit of functionality. At the command line, there are certainly a number of activities that do require superuser privileges. Examples: Editing the apache configuration file, reconfiguring sendmail, or changing the ownership on a bunch of files that you don't own to your user. Conveniently, OS X provides an appropriately configured version of sudo (superuser do) with every installation. Any user that has been given administrative rights via the GUI user management tools can also use sudo to invoke commands at the command line with superuser privileges. Everything that Fink installs is [mostly] owned by the user root. This means that a user cannot screw up or otherwise compromise the Fink installation without explicitly gaining superuser privileges to do so. When issuing Fink commands (see the Fink documentation -- it is truly awe inspiring docs for an open source project!), Fink takes care of asking the user for superuser privileges as necessary. However, to edit the Fink configuration file, you will need to gain superuser privileges to do so. Easy- from the command line, issue the command:
You can substitute any editor you want for emacs. If you want to use TextEdit, you could (that should be a single line):
(Be careful with that instance of TextEdit. It is running as root and, as such, can happily overwrite just about anything including, say, /mach_kernel -- do that and your system will be quite unhappy). Once the file is opened in your favorite editor, edit the line that starts with 'Trees:' and replace the two occurrences of the word 'stable' with 'unstable'. With fink reconfigured, you still need to update the Fink installation. Thankfully, fink can take care of that automatically. If you go to the command line and issue the command:
Fink will figure out all of the packages in the unstable/ tree that need to be rebuilt because they are newer than the same packages in stable/. It'll take care of downloading the source, applying any patches, building the various binaries/products, creating a debian package of the build products, and installing the debian package (thereby making future updates easy to apply). Fink will also take care of resolving any dependencies that the new version of the various packages may have; i.e. it'll automatically install packages that were not previously installed, if those new packages are required to upgrade one of the previously installed packages. (Did I mention how very cool Fink is? It really is a truly stellar tool. Furthermore, the fact that it comes with an extensive set of documentation, goes to great lengths to never touch Apple installed files, and generally works flawlessly is extremely commendable.) You can also use the debian package manager tool -- dselect -- to do this kind of stuff, but I never bother because I live on the point of the bleeding edge and because it is extremely handy to have the source around for the various packages that Fink can install (972, at last count).
Living on the point of the bleeding edgeIn my case, I need updates to the Fink package descriptions more recent than what is provided via the vanilla unstable/ tree and I need them more often than Fink is released (the Fink maintainers take great care in only releasing software that works-- new versions do come on a regular basis, but sometimes a release of Fink happens days before an upgrade to some random package that I need. As such, my Fink installation is against the latest contents of the Fink CVS repository. Conveniently, Fink already has an excellent built in means of automatically updating itself from the CVS repository.
The above command will update Fink-- just the packages used by the Fink engine-- to whatever is currently in CVS. It will also download the latest versions of all of the package descriptions. Once the above command has completed, simply issue:
After a 'selfupdate', the Fink package description tree contains all of the package descriptions for the absolute latest versions of all projects. As such, an 'update-all' will update all packages to the latest version. Finally, Fink packages aren't that hard to write. Most of the challenge is in the original port of the software, it is only a couple of extra steps to turn it into a Fink package description. Fink also has a Package Tracker on the sourceforge project site. Check there to see if someone has submitted a package you are looking for. If you do write a package, please submit it-- even if it is 'non-compliant' (i.e. installs binaries, etc) as the development community is working towards having a contrib/ style tree like Debian GNU/Linux. Fink isn't perfect. It exhibits two behaviors that can be confusing. The first is that some packages have dependencies that can be fulfilled by multiple possible packages. Fink will ask you which package you want to use to fulfill the dependency, but sometimes the question and answer can all be rather vague. When in doubt, go for the default. When doing updates and, sometimes, when simply installing a package, there will be those occasions when Fink fails to download something. If there is a retry from another mirror option, try that and it'll often work. If not, file a bug on the sourceforge site and it'll typically be fixed in short order. Most often, these kinds of problems are caused because the site at which the source came from has been restructured or the sourceball has been renamed. Often, simply waiting a day or two and trying again will fix the problem.
Installing PythonPython is an indispensable part of my and-- obviously, Kevin's-- development environment. Unless there is some very specific reason not to do so, use Fink to install python and choose the plain 'python' package. There is also a 'python-nox' package, but it sometimes leads to a python install that will be missing a few key components. As ugly as X11 is, it can be handy to have around anyway and Fink takes as much of the pain out of installing XFree86 as it can. I would recommend against using any of the various random 3rd party versions of X. Not because they are bad-- some of them are quite nice-- but because almost all of them (all?) are based on XFree86 anyway. By installing via Fink, you generally receive upgrades faster and the Fink developer community has an excellent track record of maintaining a top quality XFree86 package description. If you are going to use wxPython via wxgtk/X11, then the Fink installation is the way to go. It just works [now]. However, at the time of this writing, you will need to download and install a slightly custom wxmac package. This will be fixed in the near future (The command line install of python -- i.e. the version installed via Fink -- is generally called 'machopython' because it is a Mach-O binary [the native binary format for OS X] and provides the standard Python command line feature set. There is also MacPython. MacPython is a port of the OS 9 port of Python. As such, it is-- I believe-- a CFM binary and has a lot of dependencies on Carbon. It is likely that most things will move to MachoPython because it is likely that Apple will ship machopython with the system in the near future. In any case, CFM binaries suffer a fairly nasty performance penalty due to some esoteric and fairly nasty technical issues. That is, the MachoPython interpreter will be faster even though it is the same interpreter as MacPython. I have no idea what magnitude the difference is.).
To be continued....That should be enough information to yield a very powerful development configuration of OS X. What hasn't been covered and will be in the next article are all of the various wonderful resources available. They range from mailing lists to web sites to particular styles of tracking down information. The macintosh development community is incredibly strong. There are some really bright folks out there that think nothing of helping novice developers up the learning curve. As well, the next article will cover a bunch of random tools, apis, applications, and stuff that can greatly augment the OS X development and user experience. Hopefully, this article has been useful to someone. If you find errors or have comments/thoughts/requests, please feel free to send me an email. I don't have a huge amount of spare time on my hands, but I'll try to respond...
Copyright 2002 - Bill Bumgarner - |
Last update: 1/23/03; 11:01:26 .
