Interpreted languages and interpreters
V. N. Red’ko · Cybernetics and Systems Analysis · 1969
Cited by 6
Read the abstract, see who wrote it and who cites it, and get the citation in APA, MLA, Chicago or Harvard.
About 4,307 papers for “interpreted languages”
V. N. Red’ko · Cybernetics and Systems Analysis · 1969
Cited by 6
C WOOTTON · Elsevier eBooks · 2007
Cited by 1
Marcus Kracht · 2008
Question: Why did you write this book? Answer: It seems to me that the purely syntactic approach to language structure has been exhausted. More and more people are becoming convinced that what was previously diagnosed as a syntactic phenomenon really has to do with semantics. However, this really is a difficult topic, and so I thought I should work out some theory. Question: Who should read this book? Answer: Anyone who is studying linguistics and has come across the term com-positionality and wondered what on earth this means. (In other words: all those that have taken a course in semantics and want a second opinion...) Question: Will I understand the book? Answer: I obviously require some mathematical sophistication. This is not in-tended for undergraduates students. But I do not presuppose much knowl-edge of mathematics. I give many examples, which you may also study first to see what I am trying to say. If you understand Montague Semantics, you have enough background. Question: Why is there so much mathematics in it? Answer: Because we want to be certain our answer is correct. Question: Why are there so few natural language examples? Answer: Because many people think they have invalidated a theory just because one example does not work. They’d say that example sentence Number 29 has another interpretation in such-and-such context. And that in the so-and-so dialect it can mean yet another thing. But the theory is not about what exactly one particular sentence means. So I use formal examples to state my point, mostly. Question: But hasn’t Chomsky said that there is a fundamental difference be-tween formal languages (which you use all the time) and natural languages? 4
Cited by 0
Marcus Kracht · 2008
Cited by 4
Xiaoli Zhanghelen Wong · 1996
Cited by 0
Stefan Bucur, Johannes Kinder, George Candea · ACM SIGARCH Computer Architecture News · 2014
Symbolic execution is being successfully used to automatically test statically compiled code. However, increasingly more systems and applications are written in dynamic interpreted languages like Python. Building a new symbolic execution engine is a monumental effort, and so is keeping it up-to-date as the target language evolves. Furthermore, ambiguous language specifications lead to their implementation in a symbolic execution engine potentially differing from the production interpreter in subtle ways. We address these challenges by flipping the problem and using the interpreter itself as a specification of the language semantics. We present a recipe and tool (called Chef) for turning a vanilla interpreter into a sound and complete symbolic execution engine. Chef symbolically executes the target program by symbolically executing the interpreter's binary while exploiting inferred knowledge about the program's high-level structure. Using Chef, we developed a symbolic execution engine for Python in 5 person-days and one for Lua in 3 person-days. They offer complete and faithful coverage of language features in a way that keeps up with future language versions at near-zero cost. Chef-produced engines are up to 1000 times more performant than if directly executing the interpreter symbolically without Chef.
Cited by 4Open access
Stefan Bucur, Johannes Kinder, George Candea · Infoscience (Ecole Polytechnique Fédérale de Lausanne) · 2014
Symbolic execution is being successfully used to automatically test statically compiled code. However, increasingly more systems and applications are written in dynamic interpreted languages like Python. Building a new symbolic execution engine is a monumental effort, and so is keeping it up-to-date as the target language evolves. Furthermore, ambiguous language specifications lead to their implementation in a symbolic execution engine potentially differing from the production interpreter in subtle ways.
Cited by 39Open access
Gabriel Barufi Veras · Lume (Universidade Federal do Rio Grande do Sul) · 2018
Debugging a program takes time: nearly a third of the time spent in development is debugging and it seems that there is a strong correlation between the time of the first breakpoint and the time necessary to the debugging activity. The model of Swarm Debugging presents as being able to transfer the knowledge acquired in many sessions of debugging activity to future developers that would work in that same program. The model of Swarm Debugging was originally evaluated using the Java programming language being run over the Eclipse integrated development environment. This work evaluates the Swarm Debugging on the context of interpreted programming languages. Interpreted programming languages have been increasing in popularity and seven of the twenty most popular programming languages are interpreted programming languages. The meta-model of the concepts used in the Swarm Debugging is mapped to features described in the documentation of interpreted programming languages to demonstrate the possibility of supporting the Swarm Debugging in interpreted programming languages. Finally, the Firebug, an extension for Firefox web browser capable of debugging JavaScript language, and the PyDev, a plug-in to support Python language for the Eclipse integrated development environment, were changed put in practice the concepts developed in this work.
Cited by 0Open access
Maquelin, Suzanne (author) · Research Repository (Delft University of Technology) · 2022
Interpreted applications are often vulnerable to remote code execution attacks. To protect interpreted applications, we should reduce the tools available to the attackers. In this thesis, we investigate the possibilities for the automation of policy generation for interpreted applications in terms of system call arguments. These policies are used for system call argument interposition. We compare two approaches working on the interpreter to find if any of these two can provide meaningful policies. The first is dynamic analysis, and the second is static analysis, which uses symbolic execution.<br/><br/>The symbolic execution was least effective as it provides policies only for a small portion of the system call arguments, less than ten per cent, and hinders normal execution of applications with these policies. The dynamic analysis solution fares better, providing a restriction for about forty per cent of the system call arguments. We conclude that automatic policy generation of system call arguments for interpreted applications is a meaningful endeavour.
Cited by 0
Rantanen, Teemu · Aaltodoc (Aalto University) · 2020
Ohjelmiston muokkaus on toiminto, jossa tietokoneohjelma muutetaan paremmin vastaamaan käyttäjän tarpeita tai mieltymyksiä. \nMuokkauksen tarve kasvaa toimitettujen ohjelmistojen määrän myötä, tai jos ohjelmaan tarvitaan paikallisia muutoksia. \nMuokkauksella voidaan parantaa asiakastyytyväisyyttä ja tuottavuutta sekä saavuttaa huomattavaa taloudellista hyötyä. \n\nTämä työ käsittelee ohjelmiston muokkausta, jossa ohjelman ulkoinen muokkaustyökalu, esimerkiksi tulkattava kieli, on vuorovaikutuksessa ohjelmaan. \nNäiden välisen kytkennän tekeminen vaatii huomattavaa asiantuntemusta muokkauksen kohteena olevasta ohjelmistosta, muokkaustyökalusta sekä teknologiasta, jolla kytkentä suoritetaan. \nRatkaisun vaatimuksina ovat korkea suorituskyky, helppokäyttöisyys, sitoutumattomuus laitteistoalustoihin tai teknologioihin sekä tuki Microsoft COM ja Visual Basic tuotteille. \n\nTässä työssä määritellään oliojärjestelmä, jolla voi toteuttaa edellä mainitut vaatimukset. \nTyössä tutkitaan olemassa olevia muokkaustyökaluja ja teknologioita, kuten SWIG. \nLopuksi rakennetaan oliojärjestelmän toteuttava työkalu, joka sisältää helppokäyttöisen kielen ohjelmistossa toteutettavien muokkausrajapintojen ja -olioiden määrittelyyn. \nTyökalu helpottaa muokkaustoiminnallisuuden toteuttamista ohjelmassa ja takaa, että toteutettu rajapinta on yhteensopiva muokkaustyökalun kanssa. \nTyökaluun liittyy laitteistoriippumaton ajoympäristö ja kytkentä Visual Basic -kieleen. \n\nTyö rajoittuu muokkaukseen soveltuviin oliojärjestelmiin, kuten COM, CORBA, OSF DCE, Python ja Visual Basic.
Cited by 0
Ampomah Ernest, Ezekiel Mensah, A. M. Gilbert · Communications on Applied Electronics · 2017
Programmers use programming languages to develop software. But how efficiently programmers can write software depends on the translation mode that is used by them. In computing, the general modes of execution for modern highlevel languages are interpretation, compilation and hybrid. The selection of these general modes of execution is dependent on the choice of programming language. In this paper, the study compared compiled, interpreted and hybrid programming languages under translation process, execution, efficiency, portability, maintainability, and security. The paper contains idea about how software development are influenced by the decision to use compiler, interpreter or hybrid as a mode of translation hence purpose of this research. It was observed that compiled, interpreted and hybrid programming languages have their strengths and weakness, hence the need for programmers to critically analyzed their goal and how the various programming languages will help to achieve that goal before choosing a language.
Cited by 24Open access
Martin Bücker, Monika Anna Petera, Andre Vehreschild · RWTH Publications (RWTH Aachen) · 2008
Cited by 0
Jukka Ruohonen · 2021
This short paper examines the similarities and differences of software vulnerabilities reported for interpreted programming languages. Based on a sample of vulnerabilities from four software repositories (Maven, npm, PyPI, and RubyGems), the Common Vulnerability Scoring System (CVSS) and the Common Weakness Enumeration (CWE) are used for comparing the vulnerabilities across the repositories. According to the results, (i) the severity of the vulnerabilities is similar across the repositories; the median CVSS v.3 base scores are around seven. Similarity can be observed also in terms of the weaknesses underneath the vulnerabilities. In particular, (ii) cross-site scripting and input validation have been the most typical weaknesses across all four repositories. The same applies to path-traversal bugs, unauthorized accesses, and resource management bugs. With these observations, the paper contributes to the recent active research on language-specific software repositories.
Cited by 1
Tom Meyer, Tobias Helms, Tom Warnke et al. · Ros Dok Rostocker Dokumentenserver (Universitätsbibliothek Rostock) · 2018
This archive contains the needed software to execute the experiments and reproduce the results described in the paper "Runtime Code Generation for Interpreted Domain-Specific Modeling Languages" published at the Winter Simulation Conference 2018. The experiments illustrate the effectiveness of runtime code compilation of rate expressions used by the interpreted domain-specific modeling languages ML-Rules based on microbenchmarks and macrobenchmarks.
Cited by 0Open access
H Pranav, Muppavarapu Sriharshini, Rachuri Tarun et al. · 2024
On Device - translation of expression form languages with dynamic nature and using interpreted languages like MATLAB and Python requires a precise and automated form of processing the error-free conversion. With the help of the automation, the code in MATLAB is well-defined to Python so that translation is precise and the originality as well as functionality is ensured. This paper describes a robust and redundant methodology for converting maintaining the functionality and originality of the MATLAB code helping in smooth transition of code from MATLAB to python. The procedure being entirely local also ensures to protect privacy of the code.
Cited by 0
Kallenbach, Manuel · RWTH Publications (RWTH Aachen) · 2011
When working on a software project, developers usually encounter a lot of errors they have to fix.To find more information about how to solve them, they usually start to search the web, which is challenging for two main reasons: First, finding a good search query for several reasons is not easy.Second, someone has to haveusually manually -provided the necessary information before.We present a tool that tries to help with both of these problems.It consists of two components: a central server running a crowdsourced database of fixes and a client program.This client program augments a testing framework for the Ruby programming language and monitors the test executions.When a failing test is encountered, a query for related fixes is automatically generated and sent to the server.Related fixes are then displayed next to the test results for the developer's examination.When a test passes that failed before, a diff of the affected files is sent to the server and becomes part of our crowdsourced database of fixes.A preliminary evaluation between 8 developers showed that during 8 hours of programming, our tool was able to provide useful suggestions for 57% of the failing tests.During this time 161 new fixes were generated.
Cited by 0Open access
Ruian Duan, Omar Alrawi, Ranjita Pai Kasturi et al. · 2021
organizations that rely on open-source interpreted programming languages for different internal and external applications. Attackers can infiltrate well-defended organization by simply subverting the software supply chain of registries. For example, eslint-scope [4], a package with millions of weekly downloads in Npm, was compromised to steal credentials from developers. Similarly, rest-client These attacks demonstrate how miscreants can covertly gain access to a wide-range of organizations by carrying out a software supply chain attack.
Cited by 95Open access
Shawn C. Adams, Yuliang Zheng · 2024
We present a model for an alternative to Ethereum Virtual Machine (EVM) smart contract blockchain networks which relies on an interpreted programming language and a distributed file system. Specifically we present the model by integrating the Interplanetary File System (IPFS) for decentralized files storage and Python as the interpreted programming language. IPFS ensures that contract code does not change by using content/hash-based addressing. The address of the file can be passed between nodes to recreate the files locally as long as nodes are running an IPFS node as well. In this implementation, we design the model to work with an existing prototype blockchain which was built with IPFS integration. The use of Python to write the code helps ensure transparency as the code does not need to be compiled and thus would not need to be run through a decompiler to make deployed code human-readable. We describe how the data is extracted and validated from a transaction before the code is executed locally and it's respective state updated and stored on the blockchain.
Cited by 2
Cristina Ururahy, Noemi Rodriguez, Renato Cerqueira et al. · 1996
Cited by 0
Orrem, Elias Sebastian Offersoe · Duo Research Archive (University of Oslo) · 2024
Kravene som stilles til maskinvare er i stadig endring. Store datasentre og den voksende populariteten til skytjenester gjør at vi må revurdere ideer som vi tidligere kastet til siden og kalte unødvendige. Et eksempel på en slik ide er å integrere abstrakte konsepter som man finner i populære programmeringsspråk som Python, Java og JavaScript inn i prosessorkjernen ved bruk av spesialisert maskinvare. \n\nStørrelsen og energiforbruket til slike store datasentrene betyr at selv mindre forbedringer i energieffektivit representerer store kostnads og energi-besparelser. Videre har datasentrene ikke bare endret hvor programvaren kjøres, men også kravene den stiller til maskinvaren den kjøres på. Skytjenester som Functions-as-a-Service oppmuntrer utviklere til å lage små og kortvarige programmer skrevet i tolkede språk. Slikt designet programvare fungerer dårlig med den tradisjonelle prosessorkjernen, og ender derfor opp med å være både tregere og mer energikrevende enn det man på forhånd skulle anta.\n\nDenne utviklingen er motivasjonen bak forslaget om en Bytecode Front-end Modul (BFM). Ved å bruke kunnskap om detaljer rundt implementasjonen av CPython, lager vi maskinvare-optimalisert støtte for tolke-prosessen av kildekode. Ved å flytte mellomrepresentasjonen av kildekoden, bytecode, inn i det området av prosessorkjernen som er ansvarlig for spekulasjon, muligjør vi å hoppe over overflødige beregninger og instruksjoner. Dette kom av å innse det viktige og nesten konstante forholdet mellom dataverdier og generert mål i en datadreven forgrening.\n\nI utgangspunktet har vi valgt å fokusere på den kostbare operasjonen dispatch, som utgjør en betydelig andel av CPythons tolkningskostnad. Vi erstatter denne kostbare operasjonen med en optimalisert sti realisert i maskinvare. Slik reduserte vi betydelig andelen feil gjetninger og unngår unødvendige kalkulasjoner. \n\nVi bruker simulatoren ChampSim for å implementere og simulere systemet. Resultatene fra simuleringene viste en forbedring av ytelse på 21% på de mest relevante testene, og det selv når systemet brukte langt færre ressurser enn hva som kreves av en typisk moderne prediksjonsenhet. Dette viser at ideen om å bruke kunnskap om høy-abstrakte konsepter til å utvikle spesialisert maskinvare har stort potensiale. Vi tror at en slik tilnærming vil kunne være en del av en større utvikling i å fremme bærekraft og kostnadseffektivitet, særlig i slike store datasentre.
Cited by 0Open access