RE: [abc] RE: Proof-reading OOPSLA paper

Hi,

Ok, here is the second installment of my minor comments. Hopefully it is not
too late.

page 10: ...with a before/after annotationn... an extra n in the annotation
word

page 11: and then an method exit: a method exit

page 11: ...calls to the locking method need be intercepted.: I would add
'to' to the sentence so it is 'calls ... need to be intercepted'

page 12: ...to any attempt at implementing them.: suggest changing to 'to
any attempt to implement them'

page 13: several i.e. lack italics.

page 13: ...and don't contribute...: 'do not contribute' seems better

page 13: section 3 with a non-capital letter

page 13: ...this is challenge 2 (Partial Matches) that we identified
earlier.: this is THE challenge 2...

page 13: abc takes the (as far as we're aware) unique approach of
specialising to the declared tracematch variables [2].: I would change it to
: abc takes the unique approach (as far as we are aware) of specialising to
the declared tracematch variables [2].

page 13: ...as a set of Disjuncts.: why does the word disjuncts sometimes
start with a capital letter and sometimes not? Is it because you have a
class with the same name? It is not immediately obvious. in different places
disjunct has different formatting as well...

page 13: and the state on which it appears: I think it should be 'and the
state in which it appears'

page 13: how much of that trace we have already seen and what we should
expect next.: consider rephrasing this sentence, at least to: 'how much of
that trace we have already seen and what should be expected next.

page 13: The reason for our choice of DNF for representing constraints is
simplicity: suggest to change it to something like: 'The reason we choose
DNF for representing constraints is simplicity'

page 13: idividual -> individual

page 13: The alternative is to have some generic way of representing
bindings....: this is a very long sentence. I think it would be better to
make it simpler by splitting it into several sentences.

page 13: In the same sentence PatialMatch class is italic, but Object class
is not. why?

page 13: later on PartialMatch is not italic anymore. is there any
consistency?

page 13: some small measure: may be better to say: 'a small measure'

page 13: several e.g. lack italics

page 13: a minimum of runtime tests are necessary -> a minimum number of
runtime tests is necessary.

page 13: NFA, push-down automaton or alternating automaton, etc.: I suggest
to remove 'or' if there is 'etc'

page 13: in the same way that -> in the same way as

page 14: e.g. lacks italics

page 14: section 4 -> Section 4

page 15: section 4 -> Section 4

page 15: aren't -> are not

page 15: i.e. lacks italics

page 15: that will benefit all transitions, if possible.. : two full-stops
at the end of the sentence

page 15: This takes into account all tracematch symbols because all states
that that may be: remove one extra 'that'

page 16: section 4 -> Section 4

page 16-17, entire paper: sometimes the formatting of variable names is
different from the rest of the text and sometimes not. Same applies to the
names of classes

page 17: i.e. lacks italics

page 17, entire paper: just concerned about the consistency: sometimes you
write using British English, e.g. optimisation, and sometimes you write
using US English, e.g. optimization or we will...

page 17: ...because this symbol either every path leading to a final state
goes through...: probably there is a missing 'for' -> because for this
symbol either....

page 17: I think there should be a comma after For example.

page 17: sometimes dataflow, sometimes data flow

> -----Original Message-----
> From: Majordomo list server
> [mailto:majordomo@comlab.ox.ac.uk] On Behalf Of Oege de Moor
> Sent: 17 March 2006 08:48
> To: abc@comlab.ox.ac.uk
> Subject: RE: [abc] RE: Proof-reading OOPSLA paper
>
> Hi Elnar,
>
> Thanks for these very helpful comments!
>
> I've implemented them as indicated below. Eagerly awaiting
> the next instalment of your feedback...
>
> >
> > I have started reading the paper till Section 5. It looks
> pretty good
> > so far, very comprehensible, great examples, impressive numbers. I
> > especially like the offensive comments on PQL... :) Below
> are few minor suggestions.
> > I'll read the rest of the paper tomorrow morning and email
> my further
> > suggestions ASAP.
>
> thanks
>
> >
> > you say abc-an extensible compiler for aspectj both in abstract and
> > introduction. seems a bit redundant to me.
>
> I think that's ok.
>
> > page 2: we collect and develop of a set of...: I guess the
> first 'of'
> > is a bit unfortunate there...
>
> corrected
>
> > page 4: the way the patterns are specified in J-LO: I think 'the'
> > should not really be there
>
> corrected
>
> >
> > page 4: AspectJ only allows one to intercept one event at a
> time...:
> > the first 'one' seem to be redundant here
>
> corrected
>
> >
> > page 4: you say: a simple aspect might keep a couple of
> identity hash
> > maps:
> > and then it turns out that it is actually three. Probably using the
> > word several is better than a couple
>
> corrected
>
> >
> > page 4: It also possible, however, to use aspects to do
> exactly what a
> > good programmer would do by hand: 'is' is missing at the
> beginning of
> > this sentence
>
> corrected
>
> >
> > page 4: As said, it is useful to have this type of non-trivial
> > implementation as a 'gold standard' in our benchmarks: I
> think it is
> > better to start this sentence with 'As we said'
>
> corrected
>
> >
> > sometimes you write 'section X' with a capital letter and sometimes
> > not
>
> all such references (similarly for figures and tables) should
> be capital
>
> > page 4: Not all systems provide for free variables to be
> bound in the
> > matching process: i suggest to rephrase this sentence
>
> changed to:
>
> In some systems, one can bind free variables via the pattern
> matching process. When available, this feature greatly
> simplifies writing patterns that track the behaviour of
> individual object instances. It is very hard to implement
> such variable binding efficiently, however.
>
> > page 5: ...but it is also hard to implement efficiently.: does not
> > sound well
>
> see new para above
>
> > page 5: ...which indicated that its performance ranks well
> below those
> > of the systems we benchmark here...I think it is better to
> remove the
> > word 'well' because at the first look it gives a rather positive
> > feeling about HAWK
>
> well := considerably
>
> >
> > Page 6: The performance number listed was obtained by using a heap
> > size of
> > 1.5G: Is it just one number or numbers? what is 1.5G?
>
> clarified: "listed for {\sc AjNaive} was in fact obtained"
>
> >
> > page 7: These highlight the importance of...: the
> importance of what?
> > challenge N5?
>
> clarified: "These highlight the importance of the next challenge: "
>
> >
> > page 9: Binding threads is impossible in PQL at the current time: I
> > think it would be better just to say: Binding threads is currently
> > impossible in PQL.
>
> corrected
>
> >
> > page 9: strat-egy: is it a correct division of the word?
>
> erm, just living with TeX's word breaking. I don't understand
> the rules!
> >
> > page 9: .and it cannot be expressed in PQL for the same reasons as
> > that
> > example: for the same reasons as IN that example
>
> corrected
>
>
> >
> > page 9: i suggest to use * for the cases where the example is
> > expressible, but has bugs and - for the cases where the
> example is not
> > expressible. it seems more logical to me
>
> I disagree: "*" is unfortunate but honourable, "-" is shameful ;-)
>
> >
> > page 9: On the NullTrack benchmark, using an appropriate data
> > structure for organising the set of partial matches yields to a
> > speedup of a factor of
> > 6.:
> > it is not clear what yields what?
>
> deleted erroneous "to"
>
> > Section 4: for example, Weka is written using three
> different fonts.
> > is it justified? Same applies to APPROVE
>
> all should be \sc, corrected in this section.
>
> > > -----Original Message-----
> > > From: Pavel Avgustinov
> > > [mailto:pavel.avgustinov@magdalen.oxford.ac.uk]
> > > Sent: 16 March 2006 20:10
> > > To: aske@brics.dk; elnar.hajiyev@comlab.ox.ac.uk;
> dsereni@gmail.com
> > > Cc: abc@comlab.ox.ac.uk
> > > Subject: Proof-reading OOPSLA paper
> > >
> > > Hi,
> > >
> > > As you no doubt know, we have been working on an oopsla
> submission
> > > about trace monitoring features. The deadline is tomorrow, and we
> > > think we finally have a coherent enough draft to request 'outside
> > > eyes' to have a look.
> > >
> > > I have put a current (at the time of writing) version at
> > > http://musketeer.comlab.ox.ac.uk/~pavel/paper.pdf -- it is almost
> > > complete, but still misses a conclusions section, and some of the
> > > related/future work is not expanded.
> > >
> > > It would be great if you had the time to read through and
> point out
> > > any typos, inconsistencies, unnecessary repetitions or
> > > underexplained concepts that you can see. Of course, any sort of
> > > comment is helpful -- preferably in an email to abc@comlab.
> > >
> > > As I said, the deadline is very close, so we need any comments as
> > > soon as possible, tonight or tomorrow morning at the latest.
> > >
> > > To avoid biasing your judgement, I shall say no more. :-)
> > >
> > > Cheers,
> > > - P
> > >
>
>
>
>
>
Received on Fri Mar 17 14:08:30 2006