Feedback on Part 1 of the CSLP

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

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 clariﬁcation on some questions which arose in Part 1.


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.


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 :-(


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 ﬁles 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 ﬁle;
some performed a simulation.


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 speciﬁc 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.


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 ﬁle, or something else.


Understanding the problem

I received a submission with the following structure of header ﬁles 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 speciﬁcally for this
example. Please consider other example scripts available from the course
web page.


Compiling and running under Ubuntu


Compile-time errors

Compile-time errors in programs start with syntax errors and typos
such as writing down the wrong identiﬁer.
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 ﬁx, not before.
That is, unlike Eclipse, it assumes that you’re going to accept its
suggestion(!).

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.)


Unfamiliar error messages
“Duplicate symbols for architecture”

Another problem when learning a new programming language is that
the compilation process is diﬀerent 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.


StackOverflow wisdom

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


Diagnosis of the problem

This was the problem in this case: we should import header files, not
implementation files. (That is, ”.h” files, not ”.m” files.)


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 deﬁned as an instance method in
the implementation (i.e. -isUppercase). This was the problem here.


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.


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.


Incompatible pointer types
“How do I convert NSMutableArray to NSArray?”

Again, as diﬀerent from Java, Objective-C has two types of arrays,
mutable and immutable.
NSMutableArray* and NSArray* are incompatible pointer types.


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


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

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.)

Learning to love static analysis
It’s not always easy for you to see the problems in your code.
Sometimes the deﬁnition 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).

Some run-time exceptions


Feedback on Part 1 of the CSLP

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (16)

Similaire à Feedback on Part 1 of the CSLP

Similaire à Feedback on Part 1 of the CSLP (20)

Plus de Stephen Gilmore

Plus de Stephen Gilmore (16)

Dernier

Dernier (20)

Feedback on Part 1 of the CSLP