On Thu, Jul 19, 2012 at 6:54 PM, Jens Alfke
<email@hidden> wrote:
On Jul 19, 2012, at 7:28 AM, Joe Armstrong <
email@hidden> wrote:
> I assume you mean the thing that when I hover over it says in yellow "show the log navigator"?
> but I can find no "build log" (in an earlier mail you said it was "one of the tabs on the organizer"
> but the organizer is on the far right button) ...
The person who replied to you got the terminology a bit mixed up; once you use this stuff a lot you stop thinking of what they named the different pieces and just use them.
> Actually I do think this is hard since it involves several non-obvious steps. I did "click around a bit" last night (about two hours) and couldn't find what I wanted - that's why I joined this group - and thankfully got a quick reply to my question.
I hate to sound like one of those snooty guys who grunts "RTFM", but have you read the Xcode User Guide, or are you just diving in trying to figure stuff out? The user guide doesn't go too deep, but it seems pretty broad, covering pretty much every aspect of the UI. There are also quite a lot of books nowadays that cover using Xcode for Mac or iOS development.
I'm a great fan of reading manuals first - the problem is there are too many of them.
I typed "user guide" into the search window that pops up in the xcode help browser.
The result:
337 System Guides
26 Tool Guides
1 Sample code
Now I wonder which of these 337 guides is "The Xcode User guide" - there is so much
information that I'm drowning in it.
And yes - I've read two books but I was not impressed.
I finally understood how to use the interface builder by finding a utube video with
*exactly* the same version numbers as my installation and pedantically followed the instructions
until the penny dropped. I am totally amazed that the official apple user guides are wrong
they have screen dumps that differ from my installation - and I have taken care to
download the latest version.
Ever time a button is not exactly where the tutorial says it I waste minutes to hours
messing around - a complete waste of time.
Having followed the youtube tutorial I "got" the idea of an action outlet. When I drew
a control and dragged a line onto my code widow it write some code for me. Knowing
what the key concepts where I looked them up in the indices of the two books I have
only to find that they were hardly mentioned.
The books tell me how to do things and omits to tell me why. I want to understand the why first
not the how.
An NSButton has a ridiculous number of methods - but to me a button is pretty simple
it has text on it and you can click it. When you click it , it sends a message to something.
I can have 95% of all the fun with this limited knowledge - (same for entries, labels etc.)
Are their no books or libraries that offer a limed subset of the total functionality that
is suitable for a beginner?
I want a small number of primitive things that I combine to make complex things
this should be small enough that I can memorize the lot - I do not want a vast number
of potted solutions to problems that I cannot memorize.
I think my point was made by the 337 users guides - as a beginner I want to be
referred to 2 or 3 guides not 337 since I don't know where to start.
I'd like about 100 pages of clear text that talkes me through a reasonable subset of the system.
Small enough that I can memorize it - large enough to be useful. Is there such a thing?
> I'm old school - I expected the default directory for executables is the directory where I the code was.
IMHO it's a real mess for the compiler to just poop out its output all over my source directories (especially intermediate stuff like .o files.) I appreciate that Xcode tries to keep stuff organized, although I disagree about the details (I hate that the build output is now about six layers deep inside the build folder when it used to just be two.)
Yup
Also keep in mind that Xcode is optimized for building applications, not command-line tools. (Well, it does get used a lot at Apple for building the OS itself, but every component builds into its own output directory tree and then those are assembled together into an OS image.)
> Now this should be easy in objective C and X code - but all this stupid callback nonsense makes it
> horrendously complex - this grand central dispatch nonsense is a mess to make callback programming
> a tad less objectionable.
It's a matter of taste, I think. I've tried to use Erlang (for work; I'm at Couchbase) and found the basic language straightforward but the system as a whole utterly impenetrable, a twisty maze of little processes all alike. I find blocks much easier to follow. Some of this may be my history (I cut my teeth on Smalltalk back in the early '80s), but the popularity of Node.js implies others feel similarly. Anyway, that's off topic...
Interesting comment - I find splitting into process the only way to easily understand things. each process
is sequential and has a well defined protocol - it's just little black boxes talking to each other - actually
it's pure OO programming - since messages really are messages and not disguised method calls.
I find all this callback onReadCompleteDoThis(Fun) a total mess - instead
of saying
compute A - read B - compute C - read D - compute E
you say
compute A - read(B, onreadCompleteDo(Next1)
Next1: compute C - read(D, onreadcompleteDo(Next2)
Next2: ...
all because reading blocks a thread - all you need is selective non-blocking reads in a thread
and your code becomes readable :-)
having only one thread and callbacks is a hack to replace an inadequate concurrency model.
> Actually all I want to do is use the audio units on the mac which are awesome.
> All I want to say is " Instrument ! {playNote, ....}" and for a sound to be played - …
Oh boy. The Core Audio APIs are hideously complex and difficult to use, and all based on super-low-level C constructs. Definitely one of the two most frustrating APIs I've ever used (the other is the Security framework / CDSA.) Now, the newer AVFoundation framework looks a lot higher-level and cleaner, so hopefully it's easier to use. I'd recommend starting there.
I've bought a book "learning core audio" which I'm working my way through (rather slowly)
All I want is to define a few TCP or UDP ports and send the coded messages to play tones
ie if I send a packet like {play,instrument,note,duration,volume} (coded as integers) to a well known
port I'd hear some sound - should be easy (provided I can understand the core audio api :-)
and network programming.
/Joe
—Jens