Re: [abc] ECOOP strategy

I'm ok for 9:00-11:00am tomorrow (Tuesday).

Cheers, Laurie

+-----------------------------------------------------------------
| Laurie Hendren --- laurie.hendren@mcgill.ca
| Associate Dean (Academic), Faculty of Science,
| Dawson Hall, McGill University, 853 Sherbrooke St W,
| Montreal QC H3A 2T6 Canada, 514-398-7179, fax 514-398-1774
+----------------------------------------------------------------
| For contact and home page info as Professor, Computer Science:
| http://www.sable.mcgill.ca/~hendren --- hendren@cs.mcgill.ca
| Research: http://www.sable.mcgill.ca http://aspectbench.org
+----------------------------------------------------------------

On Mon, 5 Dec 2005, Pavel Avgustinov wrote:

> 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 13:17:59 2005