Download Combining reverse debugging and live programming towards visual thinking in computer ... PDF

TitleCombining reverse debugging and live programming towards visual thinking in computer ...
File Size2.6 MB
Total Pages105
Table of Contents
List of Figures
List of Listings
List of Acronyms
	Programming should be natural
	Visual ways of thinking are indispensable
	Language and visuals must be combined
	Interactive, customisable tools are required
	Interaction is governed by time
	The objective of this study
	Thesis outline
	Reverse debugging
		Reverse execution
	Live programming
		Levels of liveness
		Non-transient code
		Hot swapping
Reverse debugging
	Programming language
	Reverse mechanism
		Using Python
		Using fork
		Through recording
		Through snapshots
		Intercept mechanism
	External state
	Inter-process communication
	Back to the future
	Control of execution
	The bidirectional ldb system
		Breakpoint management
		Intercept mechanism
		External state
		Inter-process communication
		Back to the future
Live programming
	User interaction
		Awareness of change
		An IDE
	Changes to consider
		Meaningful changes
		Effective changes
	Change propagation strategies
		Execute the entire new program
		Execute up to the same position
		Execute up to the point of edit
		Avoid unnecessary execution
Conclusions and Future Work
		Approach used
		Reverse debugger
		Higher levels of liveness
	Objectives achieved
		Replacement objects
		Control of time
		Resource management
		Change propagation
	Future work
		Platform independence
		Minimising execution
		Usability studies
List of References
Document Text Contents
Page 1

Combining reverse debugging and
live programming towards visual thinking

in computer programming


Abraham Liebrecht Coetzee

Thesis presented in partial fulfilment of the requirements
for the degree of Master of Science in Computer Science at

Stellenbosch University

Computer Science Division
Department of Mathematical Sciences

Stellenbosch University
Private Bag X1, 7602 Matieland, South Africa.


Prof L. van Zijl
Dr M.R. Hoffmann

March 2015

Page 2


By submitting this thesis electronically, I declare that the entirety of the work
contained therein is my own, original work, that I am the sole author thereof
(save to the extent explicitly otherwise stated), that reproduction and pub-
lication thereof by Stellenbosch University will not infringe any third party
rights and that I have not previously in its entirety or in part submitted it for
obtaining any qualification.

20th February, 2015
Date: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Copyright © 2015 Stellenbosch University
All rights reserved.


Stellenbosch University

Page 52



For the reverse commands, a specific IC is the intended destination, as
described in the stop condition list above. The closest previous snapshot before
(or at) that IC is found and activated, with directions to forward-execute up
to the given IC if not already there. This is called counting activation, as the
stop condition depends on the instruction count.

Epdb also allows the programmer to go back to the future after reversing,
in its redo mode. If no snapshots exist between the current IC and the later
destination IC, the program simply forward-executes using the normal stop
conditions, as before. However, if one or more snapshots do exist between the
current IC and the destination IC, epdb uses forward-activation with one of
the activation types. The closest previous snapshot to the destination IC is
found, and activated with directions that depend on the command.

For the step command, it simply activates the snapshot, which will be at
the current IC + 1, so this is also counting activation.

Frame count activation is used when a next command is given. The IC
to stop at is the next one with the same frame count (or lower), which is not
necessarily the current IC + 1. Neither the snapshot to activate nor the current
main process has knowledge about what IC to stop at, as that information is
only available in their futures. The snapshot might also have a higher frame
count then the destination IC. The snapshot is therefore activated and directed
to execute up to the same frame count as that of the current main process.
This is called frame count activation, illustrated in Figure 3.7.

Figure 3.7: Frame count activation

Continue activation works in the same way, except that the destination IC
depends on the next breakpoint. The closest previous snapshot to the desti-
nation IC, or the latest snapshot in the timeline if there is none, is activated,
and directed to continue.

Stellenbosch University

Page 53


3.9 The bidirectional ldb system

Like epdb, ldb uses the bdb and pdb methodologies for implementing a de-
bugger in Python. Ldb uses the Boothe bdb debugger approach for reverse
functionality, and epdb partly served as the template for implementing it in
Python. Ldb also uses the epdb approach to resource management and break-
points, with some adjustments.

Some of the reasons why ldb is a complete rewrite and not simply an
extension of epdb, have already been mentioned. Another reason is that, due
to the complicated use of the proxy pattern, the multiprocess nature of the
debugger, and the presence of much code that is never used, epdb results in
unexpected behaviour that is difficult to resolve when trying to extend the

To resolve the difficulties that were discussed in section 3.7, ldb was created
without a redo mode, and without the concept of timelines. This facilitates
future visualisation features, and results in a less complex overall design as
well as an increase in speed through the removal of the controller process.
Without a redo mode as in epdb, ldb does not require forward activation,
so only counting activation is needed. Whenever a snapshot is activated, it
consequently does not have a future to go back to, so the next and continue
commands, which in the redo mode of epdb require frame count activation
and continue activation respectively, still work in the same way. However,
without a redo mode, nondeterministic instructions cannot be deterministically
re-executed when a program returns to its previously executed future, which is
discussed in section 3.9.5. Without timelines, multiple execution paths that
simultaneously exist are also not possible.

Some more reasons why ldb is not simply an extension of epdb, as well as
the other ways in which ldb differs from bdb, pdb, the Boothe bdb debugger
and epdb, are discussed in further detail below.

3.9.1 Breakpoint management

The breakpoint management of ldb differs from that in bdb and epdb. Bdb
does have local (to the process) breakpoint management, but as epdb and ldb
provide reverse functionality, breakpoints set in the future would be lost when
the main process ends when reversing, if a breakpoint manager is used that is

Stellenbosch University

Page 104

4, 18

[54] McLean, A. (2011). Artist-programmers and programming languages for the
arts. Ph.D. thesis, Goldsmiths, University of London. Available at: 3

[55] McLean, A., Griffiths, D., Collins, N. and Wiggins, G. (2010). Visualisation of
live code. In: Proceedings of the 2010 International Conference on Electronic
Visualisation and the Arts (EVA London), pp. 26–30. British Computer
Society, London, England. Available at: 8

[56] Mellor-Crummey, J.M. and LeBlanc, T.J. (1989). A software instruction
counter. In: Proceedings of the Third International Conference on
Architectural Support for Programming Languages and Operating Systems
(ASPLOS), pp. 78–86. ACM Press, New York, New York, USA. Available at:
02e7e523c6b6e675c6000000.pdf. 12, 38

[57] Norman, D.A. (1993). Things that make us smart: Defending human
attributes in the age of the machine. Addison-Wesley, New York, New York,
USA. 2

[58] Oney, S., Myers, B.A. and Brandt, J. (2013). Euclase: A live development
environment with constraints and FSMs. In: Proceedings of the 1st
International Workshop on LIVE Programming (LIVE), pp. 15–18. IEEE
Press, San Francisco, California, USA. Available at: http://www. 14

[59] Paivio, A. (1971). Imagery and verbal processes. Holt, Rinehart and Winston,
New York, New York, USA. 1

[60] Pan, D.Z. and Linton, M.A. (1988). Supporting reverse execution of parallel
programs. In: Proceedings of the 1988 ACM SIGPLAN and SIGOPS
Workshop on Parallel and Distributed Debugging (PADD), pp. 124–129. ACM
Press, New York, New York, USA. Available at: 11, 22, 25

Stellenbosch University

Page 105


[61] Perera, R. (2013). Interactive functional programming. Ph.D. thesis,
University of Birmingham. Available at: 6, 14

[62] Pothier, G. (2011). Towards practical omniscient debugging. Ph.D. thesis,
University of Chile. Available at:
uchile/2011/cf-pothier_g/pdfAmont/cf-pothier_g.pdf. 10, 11, 13

[63] Sabin, P. (2011). Implementing a reversible debugger for Python. Master’s
thesis, Vienna University of Technology. Available at: 12,
20, 25, 27, 30, 32, 34, 35, 36, 38, 40, 53

[64] Schiffman, J. (2001). Aesthetics of computation—Unveiling the visual
machine. Ph.D. thesis, Massachusetts Institute of Technology. Available at: 7,

[65] Stefik, A. and Siebert, S. (2013). An empirical investigation into programming
language syntax. ACM Transactions on Computing Education, vol. 13, pp.
1–40. Available at: 21

[66] Tanimoto, S.L. (1990). VIVA: A visual language for image processing.
Journal of Visual Languages & Computing (JVLC), vol. 1, no. 2, pp. 127–139.
Available at: 14

[67] Tolmach, A. and Appel, A.W. (1995). A debugger for Standard ML. Journal
of Functional Programming, vol. 5, pp. 155–200. Available at: 12, 22

[68] Vygotsky, L.S. (1978). Mind in society: The development of higher
psychological processes. Harvard University Press, Cambridge, Massachusetts.
ISBN 0674576292. 3, 7

[69] Wilcox, E., Atwood, J.W., Burnett, M.M., Cadiz, J.J. and Cook, C.R. (1997).
Does continuous visual feedback aid debugging in direct-manipulation
programming systems? In: Proceedings of the ACM SIGCHI Conference on
Human Factors in Computing Systems (CHI), pp. 258–265. ACM Press, New
York, New York, USA. Available at: 2, 14

Stellenbosch University

Similer Documents