Spelling suggestions: "subject:"bstract syntax tre"" "subject:"2abstract syntax tre""
11 |
Syntaxí řízená detekce duplicitního kódu / Syntax-driven duplicate-code detectionSaksa, Jakub January 2020 (has links)
Duplicate code occurs in source files for different reasons. In many cases the motivation for copying the code is laziness of a programmer, or an attempt to use an alien source code. Over the years, multiple methods for detection of the duplicate source code have been developed. Approaches vary in the ways they analyze the code, focusing on different representations of the program. Methods based on the analysis of the syntactic properties of the source code often use abstract syntax trees. By examining the tree representation instead of the textual representation of the code, these methods are able to detect duplicate code that underwent formatting changes as well as changes to the names of identifiers. Duplicate code fragments are discovered by identifying the subtrees of the same shape. After the suspicious parts of the tree are identified, further examination of AST properties determines to what extent the code was copied. In this work we develop a system for duplicate code detection based on AST comparison.
|
12 |
Investigating the applicability of Software Metrics and Technical Debt on X++ Abstract Syntax Tree in XML format : calculations using XQuery expressionsTran, David January 2019 (has links)
This thesis investigates how XML representation of X++ abstract syntax trees (AST) residing in an XML database can be subject to static code analysis. Microsoft Dynamics 365 for Finance & Operations comprises a large and complex corpus of X++ source code and intuitive ways of visualizing and analysing the state of the code base in terms of software metrics and technical debt are non-existent. A solution is to extend an internal web application and semantic search tool called SocrateX, to calculate software metrics and technical debt. This is done by creating a web service to construct XQuery and XPath code to be queried to the XML database. The values are stored in a relational database and imported to Power BI for intuitive visualization. Software metrics have been chosen based on the amount of previous research and compatibility with the X++ AST, whereas technical debt has been estimated using the SQALE method. This thesis concludes that XML representations of X++ abstract syntax trees are viable candidates for measuring quality of source codes with the use of functional query programming languages.
|
13 |
Determining the feasibility of automatically translating SMILE to a Java frameworkAspen, Said January 2008 (has links)
<p> </p><p>MTsim (Mobile Traffic Simulator) is an Ericsson AB internal software application that is part of 2Gsim. It is used to simulate elements of a GSM (Global System for Mobile communications) network for feature testing and automated testing. It is written in the programming language TSS Language, also known as SMILE which is a proprietary Ericsson programming language. SMILE is based on the principles of state matrix programming which in essence means that each program is on its own a finite state machine. The language is old and was originally intended as a macro language for smaller test programs, not for applications the size of MTsim.</p><p>It is of interest to evaluate the feasibility of performing an automatic conversion of applications written in SMILE, with special interest in converting MTsim, to a Java framework since Java has many advantages compared to SMILE. Java, as a language, is well suited for larger applications, there are numerous well supported tools and there is a much wider spread competence than there is for SMILE.</p><p>It is clear that in order to do a full conversion of a SMILE program to a Java framework two applications must be implemented. First a Java framework, which acts as a run time environment, must be designed which can host the translated programs. The other part is an actual translator which takes a SMILE program as input and ouputs a translated Java program. A more sophisticated framework is preferred since it makes the actual translated programs more light weight and easy to read which means higher degree of maintainability.</p><p>There are different ways to implement state machines in Java but the most flexible and versatile is to implement it as a black-box framework in an object oriented way where the framework has sophisticated mechanisms for message and event handling which is central to any state machine framework.</p><p>The translation for SMILE can easily be done by using a AST (abstract syntax tree) representation, which is a full representation of the SMILE program in tree-form. The AST is obtained from an intermediate state of the SMILE program compiler.</p><p> </p>
|
14 |
Nástroj na vizualizaci plagiátů v různých programovacích jazycích / Tool for Visualization of Plagiarism in Several Programming LanguagesBančák, Michal January 2019 (has links)
The thesis describes the design and implementation of a plagiarism tool for programming languages C, Python and PHP. It describes techniques that are used to cover a plagiarism. The aim of this work is to create a tool for detection and visualization of plagiarisms covered up using these techniques. The tool performs detection by transforming input projects into an abstract syntactic tree, which is obtained by lexical and syntactic analysis. These trees will be compared by a proposed algorithm that uses node and subtree valuation using the {hash} function. The found parts of the code that could potentially lead to plagiarism are visualized in the form of a subtree of an abstract syntactic tree that represents the parts of the code found by the tool. Further, the work describes testing of this tool on identified plagiarism techniques and specifies which of them it can eliminate. In its conclusion, the work describes the possible further development of the tool.
|
15 |
Determining the feasibility of automatically translating SMILE to a Java frameworkAspen, Said January 2008 (has links)
MTsim (Mobile Traffic Simulator) is an Ericsson AB internal software application that is part of 2Gsim. It is used to simulate elements of a GSM (Global System for Mobile communications) network for feature testing and automated testing. It is written in the programming language TSS Language, also known as SMILE which is a proprietary Ericsson programming language. SMILE is based on the principles of state matrix programming which in essence means that each program is on its own a finite state machine. The language is old and was originally intended as a macro language for smaller test programs, not for applications the size of MTsim. It is of interest to evaluate the feasibility of performing an automatic conversion of applications written in SMILE, with special interest in converting MTsim, to a Java framework since Java has many advantages compared to SMILE. Java, as a language, is well suited for larger applications, there are numerous well supported tools and there is a much wider spread competence than there is for SMILE. It is clear that in order to do a full conversion of a SMILE program to a Java framework two applications must be implemented. First a Java framework, which acts as a run time environment, must be designed which can host the translated programs. The other part is an actual translator which takes a SMILE program as input and ouputs a translated Java program. A more sophisticated framework is preferred since it makes the actual translated programs more light weight and easy to read which means higher degree of maintainability. There are different ways to implement state machines in Java but the most flexible and versatile is to implement it as a black-box framework in an object oriented way where the framework has sophisticated mechanisms for message and event handling which is central to any state machine framework. The translation for SMILE can easily be done by using a AST (abstract syntax tree) representation, which is a full representation of the SMILE program in tree-form. The AST is obtained from an intermediate state of the SMILE program compiler.
|
16 |
Editor jazyka CodAL v prostředí Eclipse / CodAL Language Editor in Eclipse FrameworkHynek, Jiří January 2013 (has links)
The Master thesis is focused on creation of an editor of CodAL language for the development toolkit of the project Lissom which is based on Eclipse framework. The goal of this thesis is to analyze the problem of editor creation and the features in existing editors which add some value to their usability. The outline of parser creation and subsequent code analysis of the source codes written into the editor is described in the theoretical part. It also explains the syntax and semantic aspects of the CodAL language. In the practical part the new CodAL language editor is designed and developed. The new CodAL language editor integrated into the development toolkit of the project Lissom is the final outcome of this thesis.
|
17 |
Optimalizace překladu agentních jazyků různé úrovně abstrakce / Optimalisation of Agent Languages CompilerKalmár, Róbert January 2012 (has links)
The aim of this work is an optimization of AHLL language compiler. Several intermediate representations of compiled code along with code optimization techniques are introduced. The main part of the work is focused on implementing these optimization techniques and generation of the target code in ALLL language. At the end of the work, the results achieved by new version of AHLL compiler are presented. In addition, there are also presented some ideas for the future work on AHLL and the compiler.
|
18 |
IDE for SCADA Development at CERN / IDE for SCADA Development at CERNMareček, Matěj January 2016 (has links)
Cílem této magisterské práce je navrhnout a implementovat IDE (integrované vývojové prostředí), které zvýší efektivitu a bezpečnost vývoje pro SIMATIC WinCC Open Architecture. Tato práce je založena na výzkumu provedeném týmem z Technické univerzity v Eindhovenu a splňuje požadavky pocházející ze SCD sekce v CERN (Evropské organizace pro jaderný výzkum). Vyvinuté IDE je postaveno na platformě Eclipse, přičemž pro syntaktickou analýzu, linkování a sémantickou analýzu kódu používá Xtext framework. IDE nabízí také podporu pro nově vytvořený programovací jazyk, který umožňuje programátorům jednoduše nadefinovat šablonu pro konfigurační soubory používané WinCC OA. Interpret tohoto nového jazyka je schopen provést syntaktickou analýzu šablony a konfiguračního souboru a rozhodnout, zdali konfigurační soubor odpovídá šabloně. Praktickým výstupem této práce je integrované vývojové prostředí, které podporuje vývoj WinCC OA aplikací v CERN a periodicky provádí analýzu kódu těchto aplikací napsaného v jazyce Control script.
|
19 |
Subtree Hashing of Tests in Build Systems : Rust Tricorder / Subträd Hashing av tester i byggsystem : Rust TricorderCapitanu, Calin January 2023 (has links)
Software applications are built by teams of developers that constantly iterate over the codebase. Software projects rely on a build system, which handles the management of dependencies, compilation, testing, and deployment of the software. The execution of the tests during each build allow developers to validate that their changes do not introduce regressions. However, the execution of the test suite during each build can take a long time, potentially impacting the development process. To facilitate quicker feedback, build systems use incremental building in order to avoid the reprocessing of unmodified artifacts. This is achieved by maintaining a cache of source files, and only rebuilding artifacts that differ from their cached version. Yet, changing any part of a source file invalidates the cache, triggering the re-execution of unmodified tests. This focus over an entire file can be misleading to the build system, as it can not determine whether the actual function being tested has changed, thus invoking redundant re-testing. In this thesis, we propose a finer-grained approach to caching within build systems, by caching components within the Abstract Syntax Tree instead of entire source files. We compare their hashes on subsequent runs, in order to identify components that have changed. The potential advantage of this strategy is that re-running a specific test that has not been modified will leverage the use of caches even if the file that contains it has been modified. We implement our approach in a system called TRICORDER, and integrate it within a build system called WARP. TRICORDER works by analyzing RUST source code in order to identify the test cases that have not been changed, such as through the addition of comments, or modifications of unrelated functions. This can benefit developers by avoiding the re-execution of tests that are unmodified. We evaluate our approach against 4 notable, open-source RUST projects, targeting a set of 16 tests within them. We first analyze the accuracy with which TRICORDER detects the internal dependencies of a test function, which is needed for the code slicing done by TRICORDER, in order to cache code items related to the target test function. We then introduce artificial changes to our study subjects in order to determine whether or not TRICORDER indicates tests that need to be re-run. Finally, we analyze the ability of TRICORDER to identify real changes based on the commit history of our study subjects. Our results show that the more granular approach to caching can avoid the unnecessary recompilation and re-execution of test cases. An important direction for future work is to extend the current implementation to support the entire set of RUST features in order to evaluate TRICORDER on a larger set of study subjects. / Programvaruapplikationer byggs av utvecklingsteam som ständigt itererar över kodbasen. Programvaruprojekt förlitar sig på ett byggsystem som hanterar beroenden, kompilering, testning och implementering av programvaran. Utförande av testerna under varje byggprocess möjliggör för utvecklare att validera att deras ändringar inte introducerar regressionsfel. Dock kan utförningen av testsviten under varje byggprocess ta lång tid och potentiellt påverka utvecklingsprocessen. För att underlätta snabbare återkoppling använder byggsystemen inkrementell byggning för att undvika onödig återbearbetning av oförändrade artefakter. Detta uppnås genom att bibehålla en cache av källkodsfilerna och endast bygga om artefakter som skiljer sig från deras cachade version. Att ändra vilken del som helst av en källkodsfil invaliderar cachet och utlöser körningen av oförändrade tester. Fokuseringen på en hel fil kan vara vilseledande för byggsystemet, då det inte kan avgöra om den faktiska funktionen som testas har ändrats och därigenom påbörjar onödig omtestning. I detta projekt föreslår vi en mer detaljerad cache-strategi inom byggsystem, genom att cacha komponenter inom det abstrakta syntaxträdet istället för hela källkodsfiler. Vi jämför deras hash-värden vid senare körningar för att identifiera ändringar. Den potentiella fördelen med denna strategi är när man kör om ett specifikt test som inte har ändrats kan cachen användas även om filen som innehåller testet har modifierats. Vi implementerar vår metod i ett system som kallas TRICORDER och integrerar det i ett byggsystem som heter WARP. TRICORDER fungerar genom att analysera RUST-källkod för att identifiera testfall som inte har ändrats, till exempel genom tillägg av kommentarer eller ändringar av irrelevanta funktioner. Detta kan gynna utvecklare genom att undvika att köra om tester som inte har ändrats. Vi utvärderar vår metod mot 4 välkända öppen källkodsprojekt i RUST och riktar in oss på en uppsättning av 16 tester inom dem. Först analyserar vi noggrannheten med vilken TRICORDER identifierar de interna beroendena hos en testfunktion, vilket behövs för kodavskärningen som TRICORDER utför för att cachelagra kodenheter relaterade till måltestfunktionen. Sedan inför vi konstgjorda ändringar i våra studieobjekt för att avgöra om TRICORDER indikerar tester som behöver köras om. Slutligen analyserar vi TRICORDER förmåga att identifiera verkliga ändringar baserat på ändringshistoriken för våra studieobjekt. Våra resultat visar att den mer granulära cachelagringsmetoden kan undvika onödig omkompilering och omkörning av testfall. En viktig riktning för framtida arbete är att utöka den nuvarande implementationen för att stödja hela uppsättningen av RUST-funktioner för att utvärdera TRICORDER på en större uppsättning studieobjekt. / Aplicațiile software sunt dezvoltate de programatori care iterează constant asupra codului. Proiectele de software se bazează pe un sistem de generare care gestionează dependențele, compilarea, testarea și lansarea software-ului. Execuția testelor permite dezvoltatorilor să valideze că modificările lor nu introduc regresii. Cu toate acestea, execuția testelor în cadrul fiecărei generări poate dura mult timp, având potențialul de a incetinii dezvoltarea. Pentru a facilita o reprocesare mai rapidă, sistemele de generare utilizează construirea incrementală pentru a evita reprelucrarea a artefactelor nemodificate. Acest lucru se realizează prin menținerea unei cache și reconstruirea doar a artefactelor care diferă de cele din cache. Cu toate acestea, orice modificare a unui fișier sursă invalidează cache-ul, declanșând reprocesarea. Focalizarea asupra unui fișier întreg poate induce în eroare sistemul de generare, deoarece nu poate determina dacă funcția testată a suferit modificări, declanșând astfel teste redundante. În această teză, propunem o abordare mai detaliată a cache-ului în cadrul sistemelor de generare, prin cacharea componentelor Arborelui Sintactic Abstract, în locul întregilor fișiere sursă. Comparăm hash-urile acestora în rulările ulterioare pentru a identifica componentele modificate. Avantajul potențial al acestei strategii constă în faptul că reexecutarea unui test care nu a nemodificat va utiliza cache-urile chiar dacă fișierul a fost modificat. Implementăm abordarea noastră într-un sistem numit TRICORDER și îl integrăm într-un sistem de construire numit WARP. TRICORDER funcționează prin analizarea codului sursă RUST pentru a identifica cazurile de testare care nu au fost modificate, cum ar fi prin adăugarea de comentarii sau modificări ale funcțiilor nerelevante. Acest lucru poate fi benefic pentru dezvoltatori, evitând reexecutarea testelor care nu au fost modificate. Evaluăm abordarea noastră în raport cu 4 proiecte notabile open-source în RUST, având în vedere un set de 16 teste în cadrul acestora. Mai întâi, analizăm precizia cu care TRICORDER detectează dependențele interne ale unei funcții de testare, ceea ce este necesar pentru tăierea de cod realizată de TRICORDER, pentru a memora în cache elementele de cod legate de funcția de testare țintă. Apoi, introducem modificări artificiale în subiecții noștri de studiu pentru a determina dacă TRICORDER indică sau nu teste care trebuie reluate. În final, analizăm capacitatea TRICORDER de a identifica schimbări reale pe baza istoricului de angajări al subiecților noștri de studiu. Rezultatele noastre arată că abordarea mai granulară a memorării în cache poate evita recompilarea și reexecutarea inutilă a cazurilor de testare. O direcție importantă pentru viitor este extinderea implementării curente pentru a sprijini întregul set de caracteristici RUST, pentru a evalua TRICORDER pe un set mai mare de subiecți de studiu.
|
20 |
Interaktivní interpret jazyka C / C Language Interactive InterpreterBlažek, Martin January 2008 (has links)
This master's thesis deals with implementation of ISO C99 language interpreter. The goal of this thesis is to provide support of education in C language programming and fast algorithm prototyping. It enables students to create own C programs and to experiment with language constructions without compiling. User interface includes editor and simple debugger. The interpreter is implemented in a novel grammar development environment written in Java language - ANTLRWorks which includes ANTLR language tool.
|
Page generated in 0.0835 seconds