Re: [abc] ECOOP strategy

I would be available till about 16:20 my time.

Eric

----- Original Message -----
From: "Prof. Laurie HENDREN" <hendren@cs.mcgill.ca>
To: <abc@comlab.ox.ac.uk>
Sent: Monday, December 05, 2005 2:17 PM
Subject: 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:52:18 2005