265 research outputs found

    Idempotent I/O for safe time travel

    Full text link
    Debuggers for logic programming languages have traditionally had a capability most other debuggers did not: the ability to jump back to a previous state of the program, effectively travelling back in time in the history of the computation. This ``retry'' capability is very useful, allowing programmers to examine in detail a part of the computation that they previously stepped over. Unfortunately, it also creates a problem: while the debugger may be able to restore the previous values of variables, it cannot restore the part of the program's state that is affected by I/O operations. If the part of the computation being jumped back over performs I/O, then the program will perform these I/O operations twice, which will result in unwanted effects ranging from the benign (e.g. output appearing twice) to the fatal (e.g. trying to close an already closed file). We present a simple mechanism for ensuring that every I/O action called for by the program is executed at most once, even if the programmer asks the debugger to travel back in time from after the action to before the action. The overhead of this mechanism is low enough and can be controlled well enough to make it practical to use it to debug computations that do significant amounts of I/O.Comment: In M. Ronsse, K. De Bosschere (eds), proceedings of the Fifth International Workshop on Automated Debugging (AADEBUG 2003), September 2003, Ghent. cs.SE/030902

    Mercury: a Model for Live Remote Debugging in Reflective Languages

    Get PDF
    Remote debugging facilities are a technical necessity for devices that have limited computing power to run an IDE (e.g., smartphones), lack appropriate input/output interfaces (display, keyboard, mouse) for programming (e.g mobile robots) or are simply unreachable for local development (e.g cloud-servers). Yet remote debugging solutions can prove awkward to use due to their distributed nature. Empirical studies show us that on average 10.5 minutes per coding hour (over five 40-hour work weeks per year) are spend for re-deploying applications while fixing bugs or improving functionality. Moreover current solutions lack facilities that would otherwise be available in a local setting because its difficult to reproduce them remotely. Our work identifies three desirable properties that an ideal solution for remote debugging should exhibit, namely: run-time evolution, semantic instrumentation and adaptable distribution. Given these properties we propose and validate Mercury, a live remote debugging model and architecture for reflective OO languages

    Out-Of-Place debugging: a debugging architecture to reduce debugging interference

    Get PDF
    Context. Recent studies show that developers spend most of their programming time testing, verifying and debugging software. As applications become more and more complex, developers demand more advanced debugging support to ease the software development process. Inquiry. Since the 70's many debugging solutions were introduced. Amongst them, online debuggers provide a good insight on the conditions that led to a bug, allowing inspection and interaction with the variables of the program. However, most of the online debugging solutions introduce \textit{debugging interference} to the execution of the program, i.e. pauses, latency, and evaluation of code containing side-effects. Approach. This paper investigates a novel debugging technique called \outofplace debugging. The goal is to minimize the debugging interference characteristic of online debugging while allowing online remote capabilities. An \outofplace debugger transfers the program execution and application state from the debugged application to the debugger application, both running in different processes. Knowledge. On the one hand, \outofplace debugging allows developers to debug applications remotely, overcoming the need of physical access to the machine where the debugged application is running. On the other hand, debugging happens locally on the remote machine avoiding latency. That makes it suitable to be deployed on a distributed system and handle the debugging of several processes running in parallel. Grounding. We implemented a concrete out-of-place debugger for the Pharo Smalltalk programming language. We show that our approach is practical by performing several benchmarks, comparing our approach with a classic remote online debugger. We show that our prototype debugger outperforms by a 1000 times a traditional remote debugger in several scenarios. Moreover, we show that the presence of our debugger does not impact the overall performance of an application. Importance. This work combines remote debugging with the debugging experience of a local online debugger. Out-of-place debugging is the first online debugging technique that can minimize debugging interference while debugging a remote application. Yet, it still keeps the benefits of online debugging ( e.g. step-by-step execution). This makes the technique suitable for modern applications which are increasingly parallel, distributed and reactive to streams of data from various sources like sensors, UI, network, etc

    A Generalized Model for Algorithmic Debugging

    Full text link
    The final publication is available at Springer via http://dx.doi.org/10.1007/978-3-319-27436-2_16Algorithmic debugging is a semi-automatic debugging technique that is present in practically all mature programming languages. In this paper we claim that the state of the practice in algorithmic debugging is a step forward compared to the state of the theory. In particular, we argue that novel techniques for algorithmic debugging cannot be supported by the standard internal data structures used in this technique, and a generalization of the standard definitions and algorithms is needed. We identify two specific problems of the standard formulation and implementations of algorithmic debugging, and we propose a reformulation to solve both problems. The reformulation has been done in a paradigm-independent manner to make it useful and reusable in different programming languages.This work has been partially supported by the EU (FEDER) and the Spanish Ministerio de EconomĂ­a y Competitividad (SecretarĂ­a de Estado de InvestigaciĂłn, Desarrollo e InnovaciĂłn) under Grant TIN2013-44742-C4-1-R and by the Generalitat Valenciana under Grant PROMETEOII/2015/013. David Insa was partially supported by the Spanish Ministerio de EducaciĂłn under FPU Grant AP2010-4415.Insa Cabrera, D.; Silva Galiana, JF. (2015). A Generalized Model for Algorithmic Debugging. En Logic-Based Program Synthesis and Transformation. Springer. 261-276. https://doi.org/10.1007/978-3-319-27436-2_16261276Eclipse (2003). http://www.eclipse.org/Barbour, T., Naish, L.: Declarative debugging of a logical-functional language. Technical report, University of Melbourne (1994)Braßel, B., Siegel, H.: Debugging lazy functional programs by asking the oracle. In: Chitil, O., HorvĂĄth, Z., ZsĂłk, V. (eds.) IFL 2007. LNCS, vol. 5083, pp. 183–200. Springer, Heidelberg (2008)Caballero, R.: A declarative debugger of incorrect answers for constraint functional-logic programs. In: Proceedings of the 2005 ACM-SIGPLAN Workshop on Curry and Functional Logic Programming (WCFLP 2005), pp. 8–13. ACM Press, New York, USA (2005)Caballero, R., Martin-Martin, E., Riesco, A., Tamarit, S.: EDD: A declarative debugger for sequential erlang programs. In: ÁbrahĂĄm, E., Havelund, K. (eds.) TACAS 2014 (ETAPS). LNCS, vol. 8413, pp. 581–586. Springer, Heidelberg (2014)Caballero, R., Riesco, A., Verdejo, A., MartĂ­-Oliet, N.: Simplifying questions in maude declarative debugger by transforming proof trees. In: Vidal, G. (ed.) LOPSTR 2011. LNCS, vol. 7225, pp. 73–89. Springer, Heidelberg (2012)Cheda, D., Silva, J.: State of the practice in algorithmic debugging. Electron. Notes Theor. Comput. Sci. 246, 55–70 (2009)Davie, T., Chitil, O.: Hat-delta: one right does make a wrong. In: Butterfield, A., (ed.) Proceedings of the 17th International Workshop on Implementation and Application of Functional Languages (IFL 2005), p. 11, September 2005Davie, T., Chitil, O.: Hat-delta: One right does make a wrong. In: Proceedings of the 7th Symposium on Trends in Functional Programming (TFP 2006), April 2006Fritzson, P., Shahmehri, N., Kamkar, M., GyimĂłthy, T.: Generalized algorithmic debugging and testing. ACM Lett. Program. Lang. Syst. (LOPLAS) 1(4), 303–322 (1992)GonzĂĄlez, J., Insa, D., Silva, J.: A new hybrid debugging architecture for eclipse. In: Gupta, G., Peña, R. (eds.) LOPSTR 2013, LNCS 8901. LNCS, vol. 8901, pp. 183–201. Springer, Heidelberg (2014)Hermanns, C., Kuchen, H.: Hybrid debugging of java programs. In: Escalona, M.J., Cordeiro, J., Shishkov, B. (eds.) ICSOFT 2011. CCIS, vol. 303, pp. 91–107. Springer, Heidelberg (2013)Insa, D., Silva, J.: An algorithmic debugger for java. In: Proceedings of the 26th IEEE International Conference on Software Maintenance (ICSM 2010), pp. 1–6 (2010)Insa, D., Silva, J.: Automatic transformation of iterative loops into recursive methods. Inf. Soft. Technol. 58, 95–109 (2015)Insa, D., Silva, J., Riesco, A.: Speeding up algorithmic debugging using balanced execution trees. In: Veanes, M., ViganĂČ, L. (eds.) TAP 2013. LNCS, vol. 7942, pp. 133–151. Springer, Heidelberg (2013)Insa, D., Silva, J., TomĂĄs, C.: Enhancing declarative debugging with loop expansion and tree compression. In: Albert, E. (ed.) LOPSTR 2012. LNCS, vol. 7844, pp. 71–88. Springer, Heidelberg (2013)Lloyd, J.: Declarative error diagnosis. New Gener. Comput. 5(2), 133–154 (1987)Lux, M.: MĂŒnster Curry User’s Guide, May 2006. http://danae.uni-muenster.de/lux/curry/user.pdf ,MacLarty, I.D.: Practical Declarative Debugging of Mercury Programs. Ph.D. thesis, University of Melbourne (2005)Naish, L., Dart, P.W., Zobel, J.: The NU-Prolog debugging environment. In: Porto, A. (ed.) Proceedings of the 6th International Conference on Logic Programming (ICLP 1989), pp. 521–536. Lisboa, Portugal (1989)Nilsson, H.: Declarative Debugging for Lazy Functional Languages. Ph.D. thesis, Linköping, Sweden, May 1998Nilsson, H.: How to look busy while being as lazy as ever: the implementation of a lazy functional debugger. J. Funct. Program. 11(6), 629–671 (2001)Nilsson, H., Fritzson, P.: Algorithmic debugging for lazy functional languages. J. Funct. Program. 4(3), 337–370 (1994)Nilsson, H., Sparud, J.: The evaluation dependence tree: an execution record for lazy functional debugging. Technical report, Department of Computer and Information Science, Linköping (1996)Nilsson, H., Sparud, J.: The evaluation dependence tree as a basis for lazy functional debugging. Autom. Softw. Eng. 4(2), 121–150 (1997)Pope, B.: A Declarative Debugger for Haskell. Ph.D. thesis, The University of Melbourne, Australia (2006)Shapiro, E.: Algorithmic Program Debugging. MIT Press, Cambridge (1982)Shapiro, E.Y.: Inductive inference of theories from facts. Technical report RR 192, Yale University (New Haven, CT US) (1981)Silva, J.: A survey on algorithmic debugging strategies. Adv. Eng. Softw. 42(11), 976–991 (2011)Silva, J.: A vocabulary of program slicing-based techniques. ACM Comput. Surv. 44(3), 1–12 (2012)Thompson, B., Naish, L.: A guide to the nu-prolog debugging environment. Technical report, University of Melbourne (1997

    An overview of the ciao multiparadigm language and program development environment and its design philosophy

    Full text link
    We describe some of the novel aspects and motivations behind the design and implementation of the Ciao multiparadigm programming system. An important aspect of Ciao is that it provides the programmer with a large number of useful features from different programming paradigms and styles, and that the use of each of these features can be turned on and off at will for each program module. Thus, a given module may be using e.g. higher order functions and constraints, while another module may be using objects, predicates, and concurrency. Furthermore, the language is designed to be extensible in a simple and modular way. Another important aspect of Ciao is its programming environment, which provides a powerful preprocessor (with an associated assertion language) capable of statically finding non-trivial bugs, verifying that programs comply with specifications, and performing many types of program optimizations. Such optimizations produce code that is highly competitive with other dynamic languages or, when the highest levéis of optimization are used, even that of static languages, all while retaining the interactive development environment of a dynamic language. The environment also includes a powerful auto-documenter. The paper provides an informal overview of the language and program development environment. It aims at illustrating the design philosophy rather than at being exhaustive, which would be impossible in the format of a paper, pointing instead to the existing literature on the system
    • 

    corecore