morris

Om man kör xcodebuild tenderar den att generera gcc-kommandon på sisådär 10-15 rader, och har man sedan några hundra filer i projektet blir det en del output att kolla igenom. Då är det väldigt smidigt att pipea bort stdout till /dev/null och bara kika på stderr.

Du borde kunna använda kvm_getprocs() med KERN_PROC_PID och din pid för att få en struct kinfo_proc som innehåller uid. Alternativt använda sysctl() med CTL_KERN/KERN_PROC/KERN_PROC_PID, men jag tror det blir samma effekt som kvm_getprocs(). Den gör skillnad på real user id och effective user id (p->e_pcred.p_ruid respektive p->e_ucred->cr_uid).

Den make som följer med Developer Tools är faktiskt GNU Make:

$ make --version
GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

self = [super initWithWidth: 0="0" andHeight: side];

self är en Square *, superimplementationen av initWithWidth:andHeight: returnerar en Rectangle *. Kompilatorn varnar för att en Rectangle inte är en Square (det omvända är dock sant). Ändra dina initmetoder att returnera objekt av typen id, istället för de explicita typerna, så slipper du varningen.

Välj ditt target, kör kommando-I för att dra upp inspektorn, leta efter Product Name.

Mach-O är en binärfil, en bundle är en mappstruktur som bland annat innehåller en Mach-O-binär. Ingemar syftar på en bundle, som är den vanligaste modellen för Cocoaapplikationer.

Backtracen med symboler:

_pmap_disconnect (in mach_kernel)
_upl_deallocate (in mach_kernel)
_ubc_create_upl (in mach_kernel)
_cluster_read (in mach_kernel)
_cluster_read (in mach_kernel)
_hfs_vnop_read (in mach_kernel)
_VNOP_READ (in mach_kernel)
_vn_rdwr_64 (in mach_kernel)
_preparefileread (in mach_kernel)
_read (in mach_kernel)
_unix_syscall (in mach_kernel)
_shandler (in mach_kernel)

Rent spontant ser den ut att krascha i filsystemet medan den läser den en fil, så det skulle kanske kunna vara disken. Dock kan det lika gärna vara minnet, om du inte kan verifiera att den kraschar på samma punkt hela tiden.

Om du har ADC-login (gratis att registrera sig på http://connect.apple.com/) kan du skicka in loggen till Apples utvecklare via http://bugreporter.apple.com/ och hoppas att du får något svar därifrån.

Objective-C Coding Guidelines kan kanske också vara intressant, även om den mest behandlar namngivning och inte så mycket syntax.

Jag antar du menar att temporärt testa att köra ditt program med en annan localization för att se att allt ser rätt ut. Du kan använda den globala defaultsnyckeln "AppleLanguages" för att ställa in språket. Den kan man sätta via kommandoraden eller applikationens argument i Xcode.

Kolla under "Build and Test" på den här URL:en:

http://developer.apple.com/documentation/Cocoa/Conceptual/NSPersistentDocumentTutorial/06_CustomisingErrors/chapter_7_section_2.html

Har kanske inte riktigt med saken att göra i övrigt, men hittade ingen bättre dokumention än det där.

#!/bin/sh

ROOTDEV=$(stat -f "%d" /)

for i in /Volumes/*; do
    DEV=$(stat -f "%d" $i)

    if [ $DEV = $ROOTDEV ]; then
        echo "$i är en mapp"
    else
        echo "$i är en monterad volym"
    fi
done

Jämför device-id för varje mapp i /Volumes mot den för /, om det skiljer sig är det en annan monterad volym.

Binären skiljer sig såtillvida att det är Intelanpassad kod som körs, men beteendet är garanterat att vara exakt likadant. Vad gäller filer beror det helt på vilken typ av fil det gäller. Textfiler som du öppnar med Cocoametoder fungerar normalt, likaså property lists, även binära. Om du däremot har ett eget filformat där du läser in t ex NSData-blobbar och plockar ut integers från det behöver du tänka på endianness. Det vill säga, alla gånger du själv hanterar binär data mellan plattformar (filer, nätverk) ska du tänka på formatet. Det finns funktioner i libkern/OSByteOrder.h för att byteswappa.

Ska du använda ett och samma värde fem gånger i samma metod är det kanske bättre att plocka ut den en gång och spara i en variabel, speciellt om det är något mer än en simpel accessor. Annars hade jag inte bekymrat mig om performance på såna här grejer, det ska du göra först när du upplever att det går långsamt och du har använt Shark för att ta reda på exakt vad det är som går långsamt. Optimera inte i förtid och optimera inte på gissningar.

Huruvida man ska kolla superklassens implementation beror lite på situationen. Ibland vill man helt ta över en implementation och inte alls låta den tidigare göra något alls, och ibland vill man bara göra lite extra före eller efter metoden. Men precis som du säger är det viktigt att se till att kedan av -init och -free (eller -dealloc i Cocoa) fungerar ordentligt. Vanligtvis får man dock varningar från kompilatorn om man försöker göra något annat.

Nej, tvärtom fungerar de endast så länge superklassen har -init och -free, eftersom båda kallar på superklassens variant med [super init/free]. Just de metoderna kommer i det här fallet från rootklassen Object. Om superklassen GraphicObject hade sin egen -init hade kedjan gått [Rectangle init] -> [GraphicObject init] -> [Object init]. Du kan titta på den kedjan själv genom att skapa en initmetod i GraphicObject, och sedan lägga in printf-satser i båda klasserna.

Jo, precis, och de som skapade sina konton innan dess och sedan har uppgraderat har tcsh. Anledningen att man länge körde med tcsh var att det är standardshell i FreeBSD, och Darwins userland hämtar till stora delar från de olika BSD-projekten, då främst FreeBSD, medan bash kommer från GNU.