429 research outputs found

    INTERACTIVE ONLINE DEBUGGER FOR INTRODUCTORY C++ PROGRAMMING COURSES

    Get PDF
    The development process for every high-level programming language is heavily dependent on integrated development environments (IDEs) or code editors, which allow software engineers to write code efficiently in terms of time consumption, clean code, and debugging. These tools are in demand for numerous reasons, including auto-completion, extensions, built-in artificial intelligence that memorizes code patterns, built-in debuggers, and readability. Almost all of the listed bullet points share one common objective, which is to alleviate the coding process for advanced users. However, during the learning process and acquisition of unknown information, priorities change. As a result, syntax and knowledge of the underlying processes of syntax take precedence over time efficiency and clean code. Moreover, the presence of those listed features can make the study process overwhelming and tedious for students, as they need to familiarize themselves with the concepts of IDEs, code editors, compilers, and debuggers before studying the programming language. It is worth mentioning that visualization is crucial in the debugging activity, since the survey conducted as a part of our research shows that 75 students out of 96 students prefer visualization during studying rather than plain text. We believe, visualization is particularly important when students start dealing with computer science concepts such as memory allocation, data structure behaviors when core methods are called, and finally, with algorithms. IDEs and code editors provide simple tables as visualizations in debugging procedures, which may not be intuitive at first glance. Another problem mentioned by professors is the distinction of hardware systems that students use. This distinction reveals the problem of installing components that work only for certain hardware systems. For instance, gdb is not suitable for new ARM circuits, whereas LLDB works properly. Meanwhile, for x86 GDB works correctly. In several courses of the School of Engineering and Digital Sciences, first-year students who take introductory courses related to high-level programming languages tend to use IDEs and code editors. Some of those courses are Engineering 101, CSCI 151, and CSCI 152. Students in those courses have faced similar problems as mentioned above. They spend time ineffectively downloading and installing components, instead of spending the same time learning actual programming. The objective of this thesis is to present a resolution for developing a comprehensive application, which allows for the visualization of the debugging process. To achieve this objective, the optimal technologies for the application will be assessed, comparing network protocols like HTTP and WebSocket, as well as examining statelessness and statefulness. The role of threads in this process will also be explored. For compiling and debugging, GCC and GDB were utilized respectively. Furthermore, the concept of a Process will be introduced to run the GCC/GDB process separately, and Input/Output streams will be explained. Finally, the thesis will explore parsing GDB responses and rendering them as a React component to provide an easily understandable visualization

    Towards the Humanisation of Programming Tool Interactions

    Get PDF
    Program analysis tools, from simple static semantic analysis by a compiler, to complex dynamic analyses of data flow and security, have become commonplace in modern day programming. Many of the simpler analyses, such as the afore- mentioned compiler checking or linters designed to enforce code style, may even go unnoticed or unconsidered by most users, ubiquitous as they are. Despite this, and despite the obvious utility that such programming tools can provide, many warnings provided by them go unheeded by programmers most of the time.There are several reasons for this phenomenon: the propensity to produce false positives undermines confidence in the validity of warnings, the tools do not in- tegrate well into the normal workflow of the developer, sometimes the warning message is simply too esoteric for most users to understand, and so on. A com- mon theme can be drawn from these reasons for ignoring the often-times very useful information given by a programming tool: the tool itself is difficult to use.In this thesis, we consider ways in which we can bridge this gap between users and tools. To do this, we draw from observations about the way in which we interact with each other in the most basic human-to-human context. Applying these lessons to a human-tool interaction allow us to examine ways in which tools may be deficient, and investigate methods for making the interaction more natural and human-like.We explore this issue by framing the interaction as a "conversation" between a human and their development environment. We then present a new programming tool, Progger, built using design principles driven by the "conversational lens" which we use to look at these interactions. After this, we present a user study using a novel low-cost methodology, aimed at evaluating the efficacy of the Progger tool. From the results of this user study, we present a new, more streamlined version of Progger, and finally investigate the way in which it can be used to direct the users attention when conducting a code comprehension exercise

    NuzzleBug: Debugging Block-Based Programs in Scratch

    Full text link
    While professional integrated programming environments support developers with advanced debugging functionality, block-based programming environments for young learners often provide no support for debugging at all, thus inhibiting debugging and preventing debugging education. In this paper we introduce NuzzleBug, an extension of the popular block-based programming environment Scratch that provides the missing debugging support. NuzzleBug allows controlling the executions of Scratch programs with classical debugging functionality such as stepping and breakpoints, and it is an omniscient debugger that also allows reverse stepping. To support learners in deriving hypotheses that guide debugging, NuzzleBug is an interrogative debugger that enables to ask questions about executions and provides answers explaining the behavior in question. In order to evaluate NuzzleBug, we survey the opinions of teachers, and study the effects on learners in terms of debugging effectiveness and efficiency. We find that teachers consider NuzzleBug to be useful, and children can use it to debug faulty programs effectively. However, systematic debugging requires dedicated training, and even when NuzzleBug can provide correct answers learners may require further help to comprehend faults and necessary fixes, thus calling for further research on improving debugging techniques and the information they provide.Comment: To appear at the 2024 IEEE/ACM 46th International Conference on Software Engineering (ICSE '24), April 14--20, 2024, Lisbon, Portuga

    A multiple case study of high school perspectives making music with code in Sonic Pi

    Get PDF
    The purpose of this study was to investigate perceptions of high school students who made music with code in Sonic Pi. This qualitative multiple case study focused on individuals in an extracurricular club at a public charter high school who volunteered to participate on-site and remotely asynchronously via Canvas learning management system. This study was guided by five research questions, including: (1) What musical ideas, if any, do participants report learning or demonstrate through making music with code in Sonic Pi? (2) How does making music with code impact participantsā€™ perceptions of their music making? (3) How does making music with code impact participantsā€™ perceptions of their ability to learn to make music? (4) How does making music with code impact participantsā€™ interest in music courses? (5) How does making music with code impact participantsā€™ interest in computer science courses? Participants completed research study materials, including a series of tutorials for Sonic Pi. Data included answers to questionnaires and surveys, multimedia artifacts including the source code and exported audio of participantsā€™ music making, and interviews of participants that were codified and analyzed in two cycles, utilizing descriptive coding, values coding, and longitudinal coding. Participantsā€™ code and multimedia artifacts revealed a close alignment to the four properties of sound, including: pitch, duration, intensity/amplitude, and timbre. Participantsā€™ artifacts revealed themes and demonstrated ideas extending beyond the four properties, including: form, non-traditional music notation, and randomization. Participants all agreed their coded artifacts are music. Additionally, participantsā€™ varied responses about musicianship and composers suggests that making music is something anyone can engage in, regardless of how one identifies themself. All participants agreed that Sonic Pi is a useful tool for learning and understanding musical concepts and that Western staff notation is not required knowledge for making music. Participantsā€™ interests in music or computer science courses were impacted by their prior experiences in music and/or coding. This study concludes with a discussion of themes based on the findings

    Proceedings of The Rust-Edu Workshop

    Get PDF
    The 2022 Rust-Edu Workshop was an experiment. We wanted to gather together as many thought leaders we could attract in the area of Rust education, with an emphasis on academic-facing ideas. We hoped that productive discussions and future collaborations would result. Given the quick preparation and the difficulties of an international remote event, I am very happy to report a grand success. We had more than 27 participants from timezones around the globe. We had eight talks, four refereed papers and statements from 15 participants. Everyone seemed to have a good time, and I can say that I learned a ton. These proceedings are loosely organized: they represent a mere compilation of the excellent submitted work. I hope youā€™ll find this material as pleasant and useful as I have. Bart Massey 30 August 202

    19th SC@RUG 2022 proceedings 2021-2022

    Get PDF

    19th SC@RUG 2022 proceedings 2021-2022

    Get PDF

    19th SC@RUG 2022 proceedings 2021-2022

    Get PDF
    • ā€¦
    corecore