[abc] ECOOP strategy

Hi all,

The deadline is fast approaching -- we have roughly 12 days now.
Tomorrow's abc meeting in Oxford will focus on paper-related discussions
(it might make sense to make it a Skype meeting if people are interested
and able -- it's scheduled for 2pm UK time, but can probably be moved a
bit).

As it stands, there's still a lot to do about the paper:

- First and foremost, more benchmarks! If we claim to be a paper giving
a quantitative and qualitative overview over the trace matching field,
we need to have a decent set of numbers. EVERYBODY should think about
this, and all those who have said they might have something suitable as
a benchmark -- please come forward now. :)
- We need to address all the italic comments/questions in the paper.
Some of them are of a rather fundamental nature ("design decisions", as
it were). Perhaps the meeting tomorrow would be the best time to do this.
- It really is time we had a complete draft of the paper. It'd be good
if everybody looked through the outline below and tried to fill in as
much as possible of the sections assigned to them.
- Closely related to the point above -- the paper's too long already!
Without even having a complete draft, we're at 28 pages at last count.
The limit is 25. One of the main problems is the huge amount of space we
waste on listings. If someone is at a loss for what else to do, it'd be
good to look into perhaps making listings appear in two columns, or
thinking of some other way of saving space.

There's probably lots more to do, but I think those are the big issues.
It's time for the final push -- less than two weeks until submission!

(Thinking of it, it probably *would* be a very good thing to have a
skype meeting asap -- can people do tomorrow?)

Cheers,
- P

Oege de Moor wrote:

>Here's a summary of what I think was said in the conference call,
>in terms of a paper organisation.
>
>I've taken the liberty of putting a name against each section -
>that means I'm hoping you'll flesh it out for next weeks call,
>trying to think of important points that must be made, papers
>that must be cited, and so on.
>
>Hopefully we can agree on the general outline beforehand
>over irc. I want to get on with it :-)
>
>
>Implementing Language Features for Program Monitoring
>-----------------------------------------------------
>
>1. Introduction [Laurie]
> (the happy story)
>
>(begin sell of program monitoring features)
>
>2. Monitoring Systems [Neil]
> (this is a hot topic, several communities working on it)
>2.1 Aspects
>2.1 Temporal logic
> J-Lo, Hawk
>2.1 Trace languages
> Tracecuts, PQL, tracematches
>
>3. Examples [Eric]
> (each example illustrates at least three of the above systems)
>3.1 Safe enumeration
>3.2 Observer
>3.3 Database connection pooling
>3.4 Changing hashcodes
>3.5 Method pairs
>3.6 Claim/release within method
>3.7 ... some example from tracecut papers ....
>3.8 ... some HAWK example ....
>
>(end sell of program monitoring features. Readers are now
> enthused: I want this! What does it cost?)
>
>4. Implementation Challenges [Pavel]
>4.1 On-line language recognition
> (running a language recogniser along your base program)
>4.2 Space leaks
> (holding on to bindings)
>4.3 Benchmark results
> (this really costs you:
> PQL, J-Lo, tracecuts, tracematches)
>
>(Hm, this looks expensive. But those numbers for tracematches
>seem pretty compelling. How was that achieved? What else can
>be done? Can the same techniques be applied in other systems?)
>
>5. Optimisation techniques
> (how come tracematches can do so well on the examples that
> are expressible in it?)
>5.1 Implemented in abc [Julian]
>5.1.1 Representing bindings
>5.1.2 Leak detection
>5.2 Other optimisations [Ondrej]
>5.2.1 ITDs to avoid binding mappings for common case
> (detailed discussion of analyses)
>5.2.2 Static prediction of paths
> (property checking analyses applied here)
>5.3 Generalising to other systems [Eric, Julian, Pavel]
> (speculation how the above techniques for tracematches
> may generalise to LTL, context-free languages...
>
>(Established it's an interesting topic now)
>
>6. Conclusion
>(Call to arms for further work, using abc as a workbench)
>
>
>
>
>
Received on Mon Dec 5 11:13:42 2005