Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About ganbustein

  • Rank
    Super Mac Geek

Profile Information

  • Location
    Berkeley CA
  1. "At the first program start" is a rather vague concept. During initialization, one thing builds on another, and you need to invoke your action after everything it depends on has been built, but before anything that depends on it. In this case, you're referring to an object in your MainWindow, so obviously you don't want it to run until that MainWindow has been built, but you want it as soon after that as possible, perhaps as a final stage in building the MainWindow. The hook you're looking for is -(void)awakeFromNib. Implement that as a method of MainWindow, and it'll be invoked as the last step of creating a new MainWindow from a Nib file. At the time it's invoked, all the items it links to will have been created, and the links to them (those instance variables that you marked as IBOutlet) will have been initialized. You're failing to understand the difference between a class and an instance of the class. MainWindow is a class, a set of behaviors common to any number of objects. An instance of MainWindow would be one of the objects exhibiting that behavior. Part of the behavior is that each particular main window has a link (what Interface Builder calls an "outlet") named "textField" to a specific instance of NSTextField. When you load the Nib file, the Nib loader will create a MainWindow, it will create an NSTextField and put a link to it in that MainWindow's textField link, it will create all the other objects you see in Interface Builder, and fill in all the links (outlets) that you defined there. Then it invokes awakeFromNib on every one of those objects that defines the method, in no particular order. You'll typically only define awakeFromNib on "parent" items, like the window, the menubar, the application controller, and let them take responsibility for finishing the initialization of their children. When you declared check_beta with a +, you identified it as a class method. A class method is handled by the class itself, and can't refer to instance variables (like textField), because it has no idea which one you mean. Each instance of MainWindow has its own textField, and there could be millions of MainWindows. (OK, in your app there can be only one, but the class doesn't know that.) You probably do want to declare check_beta as an instance method, which will be handled by a particular instance of the class. That instance will know which textField you mean, because each MainWindow only has one. But of course, you can't invoke check_beta until you have a MainWindow instance to invoke it on. Which raises the question of why you're invoking it in your .h file. A header file should contain only declarations, not executable code. Perhaps you want to call it from your awakeFromNib method? I dunno, because I have no idea what check_beta does.
  2. ganbustein

    iTunes Locked Library File

    Have you tried restarting? The reason I ask is because I saw this hint on MacOSXHints.com. (Read all the way down to the last line in the thread.) If that doesn't work, here's another hint from the same source.
  3. ganbustein

    Serial Terminal app

    Not surprising, since there aren't any serial ports to support. OK, that should take care of the physical connection. Do I understand that you're not looking for a way to connect a serial terminal so you can log into and control the Mac? You want to do it the other way around? You have existing serial equipment that you want to connect to and control from the Mac? I don't have any direct experience with it, but there is a Mac OSX Hints recommendation for minicon. The UI on the Mac would be supplied by Terminal.app, which should give you as much elegance as you can expect when talking to serial devices. Well, the T in TFTP does stand for "Trivial". If the devices you're talking to support FTP (or better yet SFTP), why not use that? But maybe I'm mistaken about what you're trying to do. If you're connecting to external devices, wouldn't the FTP server be running there, not on the Mac? Or are you trying to make the Mac a BOOTP server for them?
  4. ganbustein

    Copy/ Migrate User Account on same mac

    It turns out that "Preferences" is not one of the folder names that gets localized. Adding a .localized file has no effect, either good or ill. We might as well skip that step. (The full list of folder localizations can be found in /System/Library/CoreServices/SystemFolderLocalizations. Pick the .lproj folder for the language of interest, and examine the corresponging SystemFolderLocalizations.strings file contained within. It's a text file, and under Leopard you can just use Quick Look.) That means the correct procedure for deleting the entire preferences folder, after using su to log in as boris, reduces to: [color="#808080"]# delete all preferences, including hidden ones[/color] [color="#008000"](green lines are for Leopard only)[/color] [color="#000080"]cd ~/Library[/color] [color="#008000"]chmod -N Preferences[/color] [color="#000080"]rm -rf Preferences[/color] [color="#008000"]mkdir -m 700 Preferences chmod +a "group:everyone deny delete" Preferences[/color] And if you don't mind losing the ACL on the Preferences folder, then even simpler is to just: sudo rm -rf ~boris/Library/Preferences from an admin account that is not boris. If you have such an admin account available, and all you need to do is delete a few specific preferences, then for example: sudo rm ~boris/Library/Preferences/com.apple.{Finder,Dock}.plist
  5. ganbustein

    Mac slow web issue

    Um, OK, so you have lots of free disk space. And your user processes aren't using much of the CPU. (Nor, apparently, much RAM, but you haven't shown us what your other processes are doing.) But the question you still haven't answered is: How much RAM do you have? And while you're at it, how much of it is in use? You need to do some more poking around in Activity Monitor. At the bottom of the window, try clicking on "System Memory" instead of "CPU". Your available memory is the sum of "Free" and "Inactive". If that's small, you could well be thrashing. (If Disk Activity is also high, you're definitely thrashing.) In the top part of Activity Monitor, select "All processes" instead of "My processes". Try sorting the list on "%CPU" and on "Real Memory". (One at a time, of course.) Is any one process hogging the bulk of the resources?
  6. ganbustein

    Please help?

    For future reference, I think I figured out what went wrong (and might go wrong again). If/when it happens again, you don't need to reinstall to fix it. To make the explanation easier, I'm going to make up some names. Let's suppose: Boot volume is named Inner Other volume is named Outer Your short username is frost Your home directory is /Volumes/Outer/home/frost Now, everything is going swimmingly, until one day you boot up your machine, and for whatever reason volume Outer doesn't mount. Or doesn't mount in time. The system looks for your home directory, but it's not there. So it creates one. At /Volumes/Outer/home/frost. Think about what that means. /Volumes is the folder in which OS X normally creates mount points for volumes that it automounts. But despite this special usage, there isn't actually anything special about the folder itself. It's just a folder, and you can create ordinary folders inside it. /Volumes/Outer is now just such a folder, containing in turn the ordinary folder home/frost/. The normal unix behavior if you mount a volume at a location where a normal folder already exists is to let the mount point temporarily hide the folder. But OS X doesn't like to do that, partly because it would cause problems if you mounted two volumes with the same name. So before automount invokes the mount() function, it finds a name that's not in use. For example, when volume Outer finally shows up, it might get mounted at /Volumes/Outer1. Your original home folder is now located at /Volumes/Outer1/home/frost, but NetInfo is still pointing to the newly created home folder, at /Volumes/Outer/home/frost. The fix is simple: sudo rm -rf /Volumes/Outer (which you should of course do from a different account), followed by a restart. You did the same thing (and a whole lot more) when you did an erase and install. Be prepared, though, that the problem will return every time you log in with Outer not ready.
  7. ganbustein

    Stopping Calendar

    Put the iPod in disk use mode if you haven't already. Open it up in Finder and delete the top level folder "Calendars". Alternatively, select the iPod in iTunes, go to the Contacts tab (which oddly enough is where the Calendar settings can be found). Tell it to Sync Selected Calendars, but don't select any, and do one final sync.
  8. ganbustein

    10.4 to 10.5 file sharing issues...

    Try Go -> Connect to Server... -> afp://iMac.local. I haven't even seen my iMac in my G4's /Network/Servers list in ages, even back when both were running Tiger. (G4 is still on Tiger, iMac is on Leopard.) Even when I'm actually connect to it, I don't see it there. But I usually connect the other way anyway, just because connecting to a server is so much nicer in Leopard. I don't know what the hangup is, but I think it has more to do with network topology and/or non-standard NetInfo entries on the G4 than with an OS version mismatch. But that's just a feeling. I haven't really investigated it, since in a pinch Connect to Server works.
  9. ganbustein

    Copy/ Migrate User Account on same mac

    It might be simpler to just trash your Preferences folder. You're effectively doing that anyway, by copying over everything but. It's sometimes ineffective to trash a preference file for an application that's in use. An application typically just sucks in its preferences when it starts up and holds them in RAM. If any preference changes, it makes the change in RAM, and then completely rewriting the preference file. If you've deleted the file in the meantime, the application won't even notice. Similarly, if you've modified the preference file (using 'defaults write ...' in Terminal, for example), your change gets lost when the application updates the file with its saved values that don't reflect your change. Which means especially that it's hard to trash preferences for applications that are running all the time, like Finder and Dock. The right way to do this is to trash your preferences while the GUI is not running. Which means you have to do it in a non-GUI way. Log in as a different user. DO NOT use fast user switching here; the point is that the user whose account you're trying to clean up must not be logged in. That is, if user 'boris' needs to be cleaned up, log out of 'boris' and log in as some other user, say 'rocky'. Then have 'rocky' open Terminal. Enter the command 'su -l boris', and supply boris' password when asked. You are now logged in as 'boris' but in a non-GUI way. You can therefore delete individual preferences or the entire Preferences folder using terminal commands, with no concern that GUI applications might be trying to use the same files. [color="#808080"]# log in as boris[/color] [color="#000080"]su -l boris[/color] Password: [color="#000080"][i]<boris' password>[/i][/color] [color="#808080"]# example of how to delete individual preference file(s)[/color] [color="#000080"]cd ~/Library/Preferences rm com.apple.Finder.plist rm com.apple.Dock.plist[/color] [color="#808080"]# delete all preferences (except hidden ones)[/color] [color="#000080"]rm -rf ~/Library/Preferences/*[/color] [color="#808080"]# identify hidden preferences (which can then be deleted individually as above) # leave ".", "..", and if present ".localized"[/color] [color="#000080"]ls -al ~/Library/Preferences[/color] [color="#808080"]# delete all preferences, including hidden ones[/color] [color="#008000"](green lines are for Leopard only)[/color] [color="#000080"]cd ~/Library[/color] [color="#008000"]chmod -N Preferences[/color] [color="#000080"]rm -rf Preferences mkdir Preferences touch Preferences/.localized[/color] [color="#008000"]chmod +a "group:everyone deny delete" Preferences[/color] [color="#808080"]# resume your original identity when you're done being boris[/color] [color="#000080"]logout[/color] Notes: Don't forget to scroll the codebox above. It's not all showing. Leopard installs an ACL on most of the pre-installed folders to keep you from deleting them. The 'chmod -N Preferences' command temporarily removes that ACL. We put it back later with the 'chmod +a ...' command, so as to leave your system in a standard state. Some applications hide their preference files by prefixing them with a period. Those names become invisible, even to the wildcard *. The -a flag to ls forces invisible items to be listed. The '.localized' file that we create inside Preferences is to ensure that if you switch to a different language, Finder will properly translate the folder name "Preferences". Without that, the folder name would be stuck in English. I don't use 'sudo' anywhere above, because user 'boris' is not necessarily an admin. Once you do the 'su -l boris', you are boris, and lose whatever privileges you previously held (until you logout). This is all easier than it looks.
  10. ganbustein

    Linking Ical and Address Book

    I did something sorta kinda like that with AppleScript. I didn't like the automatic Birthday calendar, for a couple of reasons. Birthdays didn't show up in my Palm's address book. As a consequence, I also cannot enter/edit a birthday on the Palm and have it show up in Address book. The automatic Birthday calendar only shows annual birthdays. I wanted it to also track Kilodays and Kibidays. (A kiloday is 1000 days. Much more interesting than ordinary birthdays, because they're rarer. Some of my friends who are as geeky as I asked why I wasn't also tracking kibidays, which is to say, multiples of 1024 days.) So I wrote some helper AppleScripts. One of them updates the comments field (which is synchronized with Palm) to contain birthday, age, next kiloday, and next kibiday. It also looks for differences between the birthday in the comments field and in Address Book's birthday field, and propagates changes back. Another AppleScript creates new iCal events based on birthdate, distinguishing between three classes of contacts: those whose birthdays I won't celebrate anyway, those who might be amused by a "Happy Kiloday" greeting, and those who will appreciate the significance of a kibiday. These scripts don't run automatically, although I suppose I could arrange them to. As is, I run them when I think of it. But the feature that's relevant to your inquiry is that, once I've added a Birthday or Kiloday or Kibiday event to iCal, it's an ordinary iCal event, and can be customized with alarms, put on a shared calendar, whatever. You might try doing something similar. Both iCal and Address Book are readily scriptable. (One gotcha is that there's a bug in Leopard. If in AppleScript you discover that someone is, say, 22326 days old, then to get the date of their next Kiloday you might try adding 23000 days to their birthday. That works in Tiger, but in Leopard you can't add more than about 6000 days at a time. The workaround, which works in both Tiger and Leopard, is to start with their birthday and repeatedly add 1000 days until you get a date in the future. I reported this bug the week 10.5.0 came out, and it's still not fixed in 10.5.2.)
  11. ganbustein

    Do I still need OS9 or Classic?

    You don't need it and can safely throw it away. The only thing you need to watch out for is that Vintage MacOS (anything pre-OS X) would let you put documents pretty much wherever you wanted. It was not uncommon for users to store documents in the same folder as the application that created them. Even if you've long since upgraded to OS X versions of those applications, the documents may still live intermingled with your classic applications. Before trashing any classic folders, you might want to peek inside, perhaps using Spotlight to locate recently opened documents. (Search for "Last Opened" "Within Last" ... .) That having been said... Your classic System folder can have any name, but the default name is "/System Folder". By definition, a "system folder" is any folder that contains files named "System" and "Finder". Delete any of those you find, except /System/Library/CoreServices. (That's your OS X system folder, and you kinda want to keep that; all other system folders are for classic. But you don't need to search for them. The "Classic" pane of System Preferences will find them for you.) Your classic applications can be anywhere, but by default they're in "/Applications (Mac OS 9)". (Or something close to that. I long ago renamed these folders to "/Classic/System" and "/Classic/Applications", because I got annoyed that their presence interfered with autocompletion in Terminal when I wanted to look in /Applications or /System.) Delete that, along with any other classic applications you find. (Get Info will show "Kind: Application (Classic)". Use Spotlight to search for "Kind" "Others..." "Classic Application".) After deleting your classic applications, you might be able to reclaim a little disk space by rebuilding the classic desktop database one last time. (Look in System Preferences -> Classic -> Advanced.)This is a purely optional optimization that will produce a positive but probably insignificant performance boost. (Even though it's a legacy database, Launch Services still uses it, even on Leopard on Intel where there has never been any flavor of Classic. Databases work better if you eliminate useless data from them.) Your classic desktop is in a normally invisible folder named "/Desktop Folder". Since it's normally invisible, OS X automatically creates a visible alias to it, named "Desktop (Mac OS 9)" if and only if there is anything in there. If you move everything out of your classic desktop, that alias will disappear on the next restart. If you want, you can also delete "/Desktop Folder" itself, but the only space it takes up is for the invisible .DS_Store file inside, and a little space in the catalog. Do not delete /System/Library/CoreServices/Classic. That and everything else inside /System is off-limits. You can look, but don't touch.
  12. Yeah, I'd say that Core Data is overkill for this. But then, Core Data always strikes me as overkill. YMMV. (The one saving grace of overkill is that it does work. Once you get it working, anyway, although sometimes it takes a lot of work to get it working. Underkill, on the other hand, can take a lot of work to get working. Choose wisely.) For the 26 floating-point numbers, I'd just build an NSMutableArray containing 26 NSNumbers, and put that array in your defaults. Similarly for the list of timestamp/float values. Create a custom class containing an NSDate and an NSNumber. Store an NSMutableArray of those in your defaults.
  13. ganbustein

    Keep Application in Active Memory

    There's an old adage: memory management is too important to be left in the hands of the user. OK, I'm fibbing a little. The adage is usually used as an argument in favor of garbage collection, and says memory management is too important to be left in the hands of the programmer. And I'm fibbing about it being an old adage; nothing computer-related can really be said to be old. Nevertheless... If you're not using something for a while, and it gets swapped out to disk, then yes, it will take some time to read it back in. BUT while it was on disk, that RAM was being put to more productive use. (Unix doesn't swap stuff to disk just for the fun of it. It swaps stuff out when it has a better use for the RAM.) Having unused data swapped out of memory makes your computer run faster, not slower. Especially if you have limited RAM, you don't want to tie it up unproductively. Unix is doing the right thing by not giving you a say in this. (Although, 1GB isn't exactly tiny. I know modern machines can hold more, and more is better, but when I got my Intel iMac I ran it for the first week with just 512MB of RAM, just as a test, and found that it's performance was hardly shabby. After that week, I did bump it up to 2GB, the most it will handle, just because I knew I'd eventually want it. But you don't need to feel ashamed to have only 1GB. That having been said, yes, more RAM is better, and it's really cheap now.) Historical note: in the very early days of Unix, keeping applications locked in RAM (which was called Core Memory back then) was a useful optimization. For example, on a time-sharing system, it would not be unusual for several users to be running vi or sh at the same time, and it was beneficial to have their code "stick" in memory instead of giving a separate copy to each user. That was the original purpose of the "sticky" bit on a file. Modern memory management, with dynamically linked shared libraries and re-entrant code, make that optimization pointless and even quaint. The sticky bit on a file no longer has any significance.
  14. Do I understand correctly, that you want to switch from plain Cocoa to Core Data and at the same time you want to switch from non-Document to Document-based? In that case it may be easier to start over with a new project. There's not a lot of commonality between those two project types. If you're going from Cocoa Document-Based to Core Data Document-Based, it looks like the main difference (besides the presence of a .xcdatamodel, which you've already addressed) is that in the former your custom document class inherits from NSDocument, and in the latter it inherits from NSPersistentDocument. It may be enough to just change the base class. If you're going from Cocoa App to Core Data App (no documents), your File's Owner is the application, and you need to create an application delegate to respond to the managedObjectContext request. If you don't already have an application delegate, your easiest path is probably to create a new temporary XCode Core Data Application, move the CoreData_AppDelegate.{m,h} files into your existing project, and then trash the temporary project. Then let Interface Builder create an instance of it. Drag a new NSObject controller into the Main.nib, and change its class to CoreData_AppDelegate. Link it to the 'delegate' outlet of File's Owner. You will probably also need to link the main window to the CoreData_AppDelegate's window outlet. I can't be sure you won't run into other oddities further down the road. Since you're still at an early stage in the project, you won't lose much by just starting over, and the extra practice will probably do you good.
  15. ganbustein

    Text Wranger

    TextWrangler produces plain text files. You should save them with a .txt suffix. Be sure also to set the line endings to "Windows (CRLF)". The character set probably doesn't matter much as long as it's a superset of ASCII. Your best bet is probably "Western (Windows Latin 1)", although the default value of "Unicode (UTF-8, No BOM)" would probably be OK as long as you avoid non-ASCII characters. The absence of CRLF near the beginning of the file would be a not unusual reason for most Windows applications to assume the file is binary. The presence of a BOM would also confuse any application that isn't Unicode-aware. All of that is assuming that WebCT is looking for plain text files. If it's looking for something else you'll have to adapt. The easy way to find out what WebCT is expecting is to have it produce a sample document and open that in TextWrangler. TextWrangler is very good at deducing both line endings and character encoding from a sample document.