1. Computer Science Large Practical:
Feedback on Part 1 of the Practical
Stephen Gilmore
School of Informatics
Friday 9th November, 2012
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 1 / 24
2. Purpose of this lecture
To provide general feedback about Part 1 of the practical.
Give a general sense of how far people had got with Part 1, allowing
you to gauge your progress with respect to the rest of the class.
Identify some problems which people have been having.
Provide clarification on some questions which arose in Part 1.
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 2 / 24
3. Submissions for Part 1 of the practical
There are 27 people taking the Computer Science Large Practical.
There were 13 submissions for Part 1, and 14 non-submissions.
Of the 13 submissions,
4 people were developing on Ubuntu/Linux;
6 people were developing on Mac OS X;
2 people were developing on Windows 7; and
1 person was developing on Windows 8.
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 3 / 24
4. About the submissions for Part 1
Please remember when submitting to submit your entire directory, not
just the Objective-C sources.
Your directory should contain Makefiles (if developing on
Linux/Cygwin/Unix etc) or a .xcodeproj file (if developing on OS X).
These files (and possibly others, if you created them) are used to
compile your code.
Please submit all such files, as in the instruction in the practical
handout, otherwise I end up writing Makefiles to compile and run
your code :-(
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 4 / 24
5. Range of submissions for the practical
The submissions for Part 1 were obviously incomplete and
work-in-progress, as requested by the practical description.
Of the submissions for Part 1:
some were just a list of files showing the structure of the project;
some failed to compile;
some compiled but produced warnings;
some compiled and produced no warnings;
some read the simulation script file;
some performed a simulation.
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 5 / 24
6. Uncertainties about the practical, and the marking
Comment
I used GNUstep on Windows 7 to run my simulator, and used the
GCC compiler within GNUstep. I have attempted to compile my
code on the DICE machines, however it does not seem to like the
Objective-C specific elements of my code. I don’t know if there
are problems with my code or with the compiler used on the
DICE machines, but I could not get it to compile at all.
Reply
The version of GCC on DICE is an older version than most of us would
have on our laptops so some Objective-C features are not supported, and
there are other issues. As long as it compiles on your platform it is not a
problem if your code does not compile on DICE.
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 6 / 24
7. Uncertainties about the practical, and the marking
Comment
I am unsure of the fact that my application requires interaction
with the user to proceed, as I don’t know if testing of the
application for marking will be done automatically. In that case
all command line output my application produces is, of course,
useless.
Reply
Your application will not be tested automatically using a test harness; it
will be tested by a human. It is perfectly OK to ask questions of the user,
or ask them to type in the name of a file, or something else.
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 7 / 24
8. Understanding the problem
I received a submission with the following structure of header files and
classes.
compound.h enzyme.h parser.h product.h substrate.h
compound.m enzyme.m parser.m product.m substrate.m
This isn’t the right structure for this application. The enzyme/substrate
example is one possible simulation script which could be simulated. There
should not be Objective-C code in the simulator specifically for this
example. Please consider other example scripts available from the course
web page.
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 8 / 24
9. Compiling and running under Ubuntu
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 9 / 24
10. Compile-time errors
Compile-time errors in programs start with syntax errors and typos
such as writing down the wrong identifier.
Xcode suggests an alternative which is lexicographically close, a bit
like a spelling checker does.
Not that, somewhat arrogantly, Xcode shows you how your line of
code would look after you accept the suggested fix, not before.
That is, unlike Eclipse, it assumes that you’re going to accept its
suggestion(!).
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 10 / 24
11. Unfamiliar aspects of the language
One problem when learning a new programming language is that we
may bring expectations from the language which we know best.
For example, we may assume that variables are given a default initial
value (such as zero), as they are in Java.
However, this isn’t the case in Objective-C. We need to initialise
variables ourselves. (“Fix-it” in Xcode will suggest this.)
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 11 / 24
12. Unfamiliar error messages
“Duplicate symbols for architecture”
Another problem when learning a new programming language is that
the compilation process is different to the one we are used to, and
error messages may be unhelpful.
One example would be “duplicate symbols for architecture” which
occurs late in the compilation process.
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 12 / 24
13. StackOverflow wisdom
“Duplicate symbols for architecture”
A StackOverflow post
Whenever I have “duplicate symbol” errors, it is almost always
because I have a circular #import in my headers. The solution
is quite simple, use forward declarations where possible, and
#import .h files from .m files instead.
From http://stackoverflow.com/questions/11527439/i-am-having-all-the-time-this-issue-after-running-my-app
Author: Chris Trahey
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 13 / 24
14. Diagnosis of the problem
“Duplicate symbols for architecture”
This was the problem in this case: we should import header files, not
implementation files. (That is, ”.h” files, not ”.m” files.)
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 14 / 24
15. Unfamiliar error messages
“Incomplete implementation”
Another unfamiliar error message would be “incomplete
implementation”. This message has the disadvantage of being short,
and not particularly helpful.
An implementation would be described as incomplete if methods
declared in the interface were not implemented in the implementation.
This applies even if the method was declared as a class method in the
interface (i.e. +isUppercase), but defined as an instance method in
the implementation (i.e. -isUppercase). This was the problem here.
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 15 / 24
16. Conversions and coercions
We use types in programming languages to discriminate values and to
improve run-time efficiency.
Often (e.g. with numeric types), a value of one type may be
converted to another type explicitly (e.g. “floor” converts a float to
an integer) or coerced silently (e.g. integer to float).
In format strings we are also specifying the type of a value and should
specify whether we are dealing with a long or an int.
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 16 / 24
17. Conversions and coercions
Implicit coercions occur in other contexts as well, such as when we
pass a parameter to a method.
In C, and languages descended from C, the problem is made slightly
more complex because we also have unsigned integer types, which we
do not have in Java.
A conversion from long to int would lose precision, as would unsigned
int to int or, as below, unsigned long to int.
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 17 / 24
18. Incompatible pointer types
“How do I convert NSMutableArray to NSArray?”
Again, as different from Java, Objective-C has two types of arrays,
mutable and immutable.
NSMutableArray* and NSArray* are incompatible pointer types.
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 18 / 24
19. StackOverflow wisdom
“How do I convert NSMutableArray to NSArray?”
A StackOverflow post
An NSMutableArray is a subclass of NSArray so you won’t
always need to convert but if you want to make sure that the
array can’t be modified you can create a NSArray either of these
ways depending on whether you want it autoreleased or not:
/* Not autoreleased */
NSArray *array = [[NSArray alloc] initWithArray:mutableArray];
/* Autoreleased array */
NSArray *array = [NSArray arrayWithArray:mutableArray];
From http://stackoverflow.com/questions/1768937/how-do-i-convert-nsmutablearray-to-nsarray
Author: M Hallendal
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 19 / 24
20. Other wisdom
An iPhoneDevSDK post
NSMutableArray *myMutableArray = [myArray mutableCopy];
NSArray *myArray = [myMutableArray copy];
There’s not much reason to do the second one since
NSMutableArray does everything that NSArray does, unless you
expect the mutable array to change and you want a copy of its
current state. Two things to keep in mind: (1) both of these
methods return an object with a retainCount of 1, just like
alloc+init does. You own these objects and must release them
somewhere. And (2) neither method makes copies of the items
themselves, just the pointers.
From http://iphonedevsdk.com/forum/iphone-sdk-development/62801-nsmutablearray-to-nsarray.html
Author: smasher
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 20 / 24
21. Learning to love static analysis
Sometimes static analysis will complain about parts of your code
where you are sure that there is nothing wrong.
The way you see your code:
The way static analysis sees your code:
Think of static analysis as “your slightly less clever friend” and try to
help it to see that your code will never produce a run-time error. (You
can do this by, for example, initialising variables.)
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 21 / 24
22. Learning to love static analysis
It’s not always easy for you to see the problems in your code.
Sometimes the definition site for a variable is many lines away from
the use site.
Static analysis provides an over-approximation of your program’s
behaviour. It reports potential problems which might not occur in
practice (but “your slightly less clever friend” can’t see that).
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 22 / 24
23. Some run-time exceptions
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 23 / 24
24. Some run-time exceptions
Stephen Gilmore (School of Informatics) Computer Science Large Practical Friday 9th November, 2012 24 / 24