Hi Ivan, TESLA has a web site, which covers getting started:
http://www.cl.cam.ac.uk/research/security/ctsrd/tesla/build.html For the traces, I actually replaced the debugging printf handler to log the raw events. We're hopefully going to separate TESLA into some cleaner layering, so the event-generation code is more isolated from the event-handling code and we can more easily plug other bits of tracing into it. If you just want traces of message sends, then the latest version of the runtime has a mechanism for interposing on a particular selector, which is what TESLA uses. David On 23 Dec 2013, at 15:49, Ivan Vučica <[email protected]> wrote: > Thread necromancy! > > During GSoC2013, I would have loved to have something like the contents of > "Drawing.log", annotated with screenshots and perhaps some additional state > etc. As you mentioned, it would have helped a lot in development of the Opal > backend. > > Is something like generating screenshots (or making a function call), then > integrating an <img src=""> inside the log, possible with TESLA? > > Any instructions on using TESLA? > > On Wed Oct 02 2013 at 3:59:25 PM, David Chisnall <[email protected]> wrote: > Hello all of the GNUstep developers, > > We've recently been working on a tool called TESLA that allows you to write > temporal assertions (e.g. before you get here, this other function must have > been called and returned this value) that are checked at run time, but also > provides a convenient way of adding instrumentation to programs. > > I've uploaded a couple of profiling traces to give people an idea of the > kinds of thing this can generate: > > http://theravensnest.org/Drawing.log > http://theravensnest.org/NSCursor.log > > The first is a log of all of the drawing messages in the protocol defined by > NSGraphicsContext (i.e. the thing used to communicate between -gui and > -back), indented based on the current view and cell that is responsible for > the drawing. This doesn't provide a full stack trace, just some context. > The motivation for this is Ivan's work on the Opal back end, and looking at > exactly how the back end is used. Are we doing too many pushes and pops of > graphics state, or saving and restoring when we don't need to? Are we > calling methods a lot that are poorly optimised in the back end? > > The second is a stack trace, generated in every place where we call a push or > pop method. The motivation for this was the recent work trying to find bugs > in the NSCursor balancing code. Unfortunately, I wasn't able to reproduce > the bugs when I tried (maybe they're all fixed?) and so this isn't very > useful, although it might be interesting. > > Can anyone else think of other useful traces that we might want to generate? > > David > > -- Sent from my Apple II > > > _______________________________________________ > Gnustep-dev mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnustep-dev -- Sent from my Cray X1 _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
