Per Persson

Vet iofs inget om MacCVSClient, men har själv använt CVL (Concurrent Version Librarian) från Sen:te ett par år och tycker att det funkar alldeles utmärkt.

CVL är alltså ett GUI för CVS, inte ett versionshanteringssystem i sig.

/Per

Lysande initiativ! Skulle du kunna tänka dig att skicka samma mail till övriga partier (representerade i EU-parlamentet) så att man kan få en komplett bild av insikt/åsikt hos våra företrädare??

Kolla att Enable SCM är ikryssat i info-fönstret för projektet. Verkar nollställas om man inte får kontakt med servern, t.ex. från en powerbook när man jobbar off-line.

Online member, som de flesta här.

För att förvirra ytterligare och locka till bokköp:
Man anropar inte metoder från objekt, man skickar meddelande till dem. Det kan tyckas petigt med skillanden, men det är ofta så att objekt skickar vidare meddelanden istället för att hantera det själv.
Det här är på sätt och vis den fundamentala skillnaden mellan ObjC och Java/C++.

Tänk på motsvarigheten till printf("nummer %d och %d\n", 1 2) i C, du vet inte hur många argument du har förrän du läst det första (och obligatoriska) argumentet. I ObjC:
[NSString stringWithFormat:@"nummer %d och %d och en hälsning %@", 1, 2, @"Hello world!"];

Fish på KB?!

Det finns naturligtvis gprof (man gprof) men även andra, ffa shark och CHUD-tools.

Se http://developer.apple.com/tools/performance/

/Per

Samuel K skrev

??? Kan du precisera lite närmare...
Antar att du tänker på retain-cycles, men då är minst två objekt inblandade.

Är det inte sånt här som MRJAppBuilder är till för?

(/Developer/Applications/MRJAppBuilder)

/Per
(kan absolut nada om Java, så ställ inga följdfrågor...

Förlåt mig om jag är en party-pooper, men jag tror inte att Chess.app har en resursdel...

Därmed inte sagt att LFH's one-liner inte är elegant

Glömde att tipsa om ConvertMake, som automagiskt gör om makefiler till PB-projekt:
http://homepage.mac.com/walisser/convertmake/

/Per

Genom att välja "legacy makefile" kommer PB vanliga build-system att sättas ur spel och istället säger PB bara "make" och sen utförs instruktionerna i makefilen. Du behöver inte trixa alls.

Kolla här:
http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/compiling/chapter_4_section_2.html#//apple_ref/doc/uid/DontLinkBookID_82-CH206-BBCJABGC
finns på din disk oxå.

öhh, det ser inte ut som om du kör make-filen.

Project->New Target...
välj Legacy Makefile och nåt namn.

välj sen denna target.

(sorry för kort & kärvt, bebis på axeln;-)

Hej,
det här med att ärva är inte alls lika vanligt i ObjC som i t.ex. C++. Skälet till det ligger i designfilosofin bakom resp. språk.

Den vanligaste (om man får uttrycka sig så vagt) formen av klasser ärver direkt från NSObject (rotklassen) och bygger sedan upp funktionalitet mha "composition" dvs ett antal instanser av diverse klasser.

Jämför frågan "är en ..." respektive "har en ...". Exv. min klass är en lista kontra min klass har en lista.

Vissa klasser är inte alls avsedda att ärvas från, t.ex. generiska container-klasser som NSArray/Dictionary/Set. Det finns sällan behov av det eftersom de kan innehålla alla andra sorters objekt. Jfr. C++ som kräver(?) att du deklarerar vilken typ av objekt som ska lagras.

Känner man att man bara måste ha någon viss funktionalitet så är kategorier antagligen tillräckliga, som påpekats tidigare.

Ett fåtal klasser är att betrakta som "abstrakta" (begreppet saknar betydelse i ObjC), t.ex. NSView som måste subklassas.

För att se hur ovanligt ärvning är, så öppna fliken Classes i PB och välj Hierarcy, all classes i pop-up menyn.
De flesta klasser ärver bara från NSObject, somliga ärver i ett led (t.ex. NSArray -> NSMutableArray), medan ett fåtal har en lång kedja t.ex. NSResponder (i AppKit).

Som sagt, ObjC har en annan OO-filosofi än C++ (som lärs ut i parti och minut vid universitet och högskolor...)

/Per

Tyvärr, såld. Gick på studs.

/P