Per il corso di "Automi, Linguaggi e Complessità", le slide sulle Espressioni Regolari: definizioni, la loro implementazione tramite Automi Finiti, i metacaretteri di PCRE, ecc...
co-authors: Scola Davide and Maia Nicoletta
Small workshop on Inferno, Limbo and the Dis virtual machine.
Inferno is a new operative system developped for creation and support of network systems and distribuited services.
There are three fundamental programming principles: all resources are files in a hierarchic file system, the network is a unic namespace like a file system hierarchic, it uses Styx that is a standard protocol of comunication for local and remote resources.
Limbo is the programming language for the Inferno OS.
The language is Object Based, you can compile it or interpret it with the Dis virtual machine (like Java virtual machine with a JIT compiler).
Limbo has a native support for: array, string, int, float, tuple (like record), channel (linda-like), and other...
The Limbo's channels are used to comunicate with other processes or with thread.
The Dis virtual machine is an environment for Limbo programs and it has important features: CISC architecture, memory-to-memory, many high level types, just in time compiler, ecc...
In the end of presentation there is a comparison between Dis, Java VM and C# .Net VM.
The document discusses various topics related to urban planning, design, and research including how engineers shape urban spaces, using tools like GPS and GIS, housing projects in Bolivia, the relationship between producers, clients, and users, standardization aids, teachers summarizing for students, intervisibility and safety, the complexity of planning requiring multiple sectors, spatial visions as action plans not final products, pre-research mapping, integrating top-down and bottom-up approaches, and presenting assignments.
Per il corso di "Automi, Linguaggi e Complessità", le slide sulle Espressioni Regolari: definizioni, la loro implementazione tramite Automi Finiti, i metacaretteri di PCRE, ecc...
co-authors: Scola Davide and Maia Nicoletta
Small workshop on Inferno, Limbo and the Dis virtual machine.
Inferno is a new operative system developped for creation and support of network systems and distribuited services.
There are three fundamental programming principles: all resources are files in a hierarchic file system, the network is a unic namespace like a file system hierarchic, it uses Styx that is a standard protocol of comunication for local and remote resources.
Limbo is the programming language for the Inferno OS.
The language is Object Based, you can compile it or interpret it with the Dis virtual machine (like Java virtual machine with a JIT compiler).
Limbo has a native support for: array, string, int, float, tuple (like record), channel (linda-like), and other...
The Limbo's channels are used to comunicate with other processes or with thread.
The Dis virtual machine is an environment for Limbo programs and it has important features: CISC architecture, memory-to-memory, many high level types, just in time compiler, ecc...
In the end of presentation there is a comparison between Dis, Java VM and C# .Net VM.
The document discusses various topics related to urban planning, design, and research including how engineers shape urban spaces, using tools like GPS and GIS, housing projects in Bolivia, the relationship between producers, clients, and users, standardization aids, teachers summarizing for students, intervisibility and safety, the complexity of planning requiring multiple sectors, spatial visions as action plans not final products, pre-research mapping, integrating top-down and bottom-up approaches, and presenting assignments.
This document discusses software services and cloud computing architectures. It begins by providing context on the growing service economy and how businesses are increasingly offering services rather than products. It then defines software-as-a-service (SaaS) and describes how SaaS delivers software applications over the internet, with updates and management occurring remotely. Finally, the document discusses service-oriented architectures and how they support the development and delivery of software services.
Con un approccio pratico, e ricco di esempi semplici per illustrare bene i concetti, impara le basi del linguaggio di scripting Bash, ormai divenuto uno standard de facto in termini di scripting di shell (Shell Scripting).
La presentazione si compone di 12 lezioni / capitoli:
1 - Introduzione
2 - Primi passi
3 - Variabili
4 - Array
5 - Aritmetica
6 - Test
7 - Costrutti condizionali
8 - Cicli iterativi
9 - Funzioni
10 - Quoting
11 - Terminare uno script
12 - Debugging
Per un totale di 98 diapositive
Domain Specific Languages: implementazione in Lisp e integrazione con Java mediante API JSR-223.
Presentazione tenuta il 20/01/2009 in occasione dell'incontro del JUG Genova.
Dynamic Language Programming For The Statically Typed ProgrammerMarco Parenzan
Un programmatore di C# (statically typed language) che usa un Dynamic Language
http://codeisvalue.wordpress.com/2010/01/23/post-ugi-alt-net-conference/
Studio dei tre tools di analisi CFlow , Fjalar e Metre. Verranno messi a confronto per i loro requisiti di installazione, semplicità di utilizzo e funzionalità offerte.
Intro a Linux tenuta all'università degli studi di Napoli Federico II. Speaker: Gabriele Previtera - https://www.linkedin.com/in/gabriele-previtera-6657648b/
The document discusses architecture-centric software development processes. It describes traditional waterfall and iterative development models, and notes that iterative models allow for more flexibility to changing requirements. Agile development methods like eXtreme Programming (XP) are discussed, which emphasize iterative development, collaboration, and rapid delivery of working software. Key practices of XP are outlined, including user stories, testing, pair programming, refactoring, and continuous integration. The role of architecture in agile processes is also addressed.
This document discusses software product lines and product line architectures. It defines a software product line as a set of software systems that share a common set of features addressing a particular market segment. Product lines are developed from a common set of core assets in a prescribed way to reduce costs and increase reuse. A product line architecture is a common framework that standardizes components and maximizes reuse potential. It specifies common functionality and identifies variation points across related products. Variability management is important for providing flexibility without compromising commonality.
6 - Architetture Software - Model transformationMajong DevJfu
This document discusses model transformations in Model-Driven Architecture (MDA). It defines computation independent models (CIMs), platform independent models (PIMs), and platform specific models (PSMs). It explains that model transformations are used to map between these different abstraction levels and ensure consistency. It also discusses model mappings, approaches to transformations, and tools like EMF and ATL that support transformations in Eclipse.
5 - Architetture Software - Metamodelling and the Model Driven ArchitectureMajong DevJfu
The document discusses metamodeling and the Model Driven Architecture (MDA). It covers topics such as model driven engineering, metamodeling, metamodeling in UML, and the OMG technologies that support MDA. Metamodeling involves modeling modeling elements and their relationships. Metamodels define the structure of models, while models are instances that conform to metamodels. The MDA uses metamodels and models to develop and transform systems.
This document provides an overview of software architectures by presenting examples of architectures from various software systems. It begins with an introduction to software architecture and what it entails. It then shows numerous diagrams and visualizations of architectures for different types of systems, such as editors, compilers, operating systems, middleware, and web applications. These examples are intended to demonstrate common architectural patterns and styles. The document discusses analyzing and comparing the architectures visually and recognizing patterns within them.
The document discusses architectural styles and decomposition techniques for software systems. It describes layering and tiering as basic decomposition approaches, with layers representing different levels of abstraction and tiers representing peer modules within the same layer. Several common architectural styles are then introduced, including pipes and filters, repository, client/server, model-view-controller, service-oriented, and peer-to-peer. Closed and open layered architectures are contrasted, and examples of layered systems like virtual machines and the OSI model are provided. Finally, the document notes that complete decompositions often involve both layering and partitioning techniques.
The document discusses key concepts in software architecture, including:
1) Software architecture establishes the overall structure and organization of a system, including its components and relationships.
2) Architectural design involves decomposing a system into subsystems or modules to improve modifiability, reusability, and portability.
3) Key principles for architectural design include simplicity, modularity, low coupling, separation of concerns, abstraction, and postponing decisions.
1 - Architetture Software - Software as a productMajong DevJfu
This document discusses software as a product and industry. It covers how software is a key component in modern technologies and industries. The software industry has grown significantly in recent decades. The document discusses different types of software such as embedded software, middleware, and software as a service. It also covers topics like software architecture, engineering, components, ecosystems, and the challenges in developing software. Overall, the document provides an overview of software as an industrial product and the software development industry.
10 - Architetture Software - More architectural stylesMajong DevJfu
The Microkernel pattern partitions an operating system into isolated, minimal components that communicate through a small, fixed message-passing interface, allowing components to be developed and upgraded independently while maintaining overall system stability and security.
The document discusses architectural UML and provides information on:
1) The elements of a software architecture including views, models, and diagrams.
2) How UML can be used to represent different architectural views including design, process, development, and physical views.
3) An example of using UML models and diagrams to represent different views of a chess game architecture.
UML allows for extending diagrams and modeling elements through three main techniques:
1. Stereotypes allow applying tags to existing modeling elements like classes, associations, etc. to add domain-specific meaning.
2. Profiles extend UML with new modeling elements tailored for specific domains or platforms.
3. Extension mechanisms allow precisely defining new constructs that integrate with the UML metamodel. Together these techniques make UML extensible for multiple domains.
The document discusses metamodeling and the Model Driven Architecture (MDA). It provides an overview of model driven engineering and metamodeling. Specifically, it discusses how metamodels define the structure of models through concepts like classes and relationships. The Model Driven Architecture uses metamodels and modeling to develop software systems from models.
Here are the key differences between objects and classes in UML:
- Classes define the general characteristics (attributes and operations) that objects of that class will have. Objects are specific instances of a class.
- Classes are static definitions, while objects are dynamic instances of classes that exist at run time.
- In class diagrams, classes are represented as boxes containing the attributes and operations. Objects are represented as boxes with the class name followed by a colon and the object name (e.g. Person:John).
- Classes define the common properties for a set of objects, while each object is a unique instance of a class with its own identity and particular values for attributes.
- Classes are abstractions,
The document discusses architectural styles and decomposition techniques. It describes layers as hierarchical sets of subsystems that provide related services by utilizing underlying layers. Tiers partition a system into peer subsystems responsible for classes of services. Common architectural styles include pipes and filters, repository, client/server, model-view-controller, service-oriented, and peer-to-peer. Layers and tiers are often combined for complete decomposition, with subsystems divided into tiers and each tier organized into layers. The pipe and filter style focuses on dynamic interaction by processing data streams through filters connected by pipes.
- Reference architectures that provide templates for common system types
- Design patterns that capture successful solutions to recurring problems
- Architectural patterns that describe best practices for system organization
- Legacy applications that can be analyzed for reusable architectural elements
This document discusses software as a product and the software industry. It covers topics such as why software is important, emerging technologies according to Gartner's hype cycle from 2005-2010, software being an industrial product, the size of the worldwide software industry, different types of software including embedded software and software as a service. It also discusses software components, software architecture and engineering issues, producing software is difficult due to complexity, low productivity in the industry, the software development process, different process models, lifecycle differences around the world, development activities, process models, and software standards.
This short document contains 5 headings but provides no other details or context. It lists the headings "My Heading Here First Second Third Fourth Fifth" but does not elaborate on or explain these headings.
This document provides an overview of various types of architectural standards including conceptual standards like IEEE 1471 and DoDAF that define viewpoints and views, notational standards like UML and SysML, and process standards like TOGAF and RUP. It discusses the benefits of standards in promoting interoperability and network effects while also noting drawbacks like limiting flexibility. The document advises deciding when to adopt a standard based on whether in the early or late phase of a project.
The document discusses architectural adaptation and software evolution. It characterizes different types of changes that can occur, including corrective changes, new features, and changes to the operating environment. It also describes different levels at which changes can be made, from the component interior to the overall system configuration. Effective adaptation requires techniques like explicit architectural models, adaptable connectors, and message-based communication. The roles of change agents, strategic and tactical planning, and quiescence are also outlined.
1. Parte 1
Un esempio di
ambiente di esecuzione:
il Perl
Linguaggi dinamici – A.A. 2009/2010
1
2. Ciclo di vita di un programma Perl
„ Il ciclo di vita di un programma scritto in Perl si
compone di quattro fasi successive
(due opzionali, due obbligatorie)
1)Compilazione (obbligatoria)
2)Generazione di codice (opzionale)
3)Ricostruzione del parse t
3)Ri t i d l tree (
(opzionale)
i l )
4)Esecuzione (obbligatoria)
„ Fasi gestite dall'eseguibile /usr/bin/perl
„ Le fasi opzionali sono dovute al fatto che un
programma in Perl può anche essere
compilato per generare un eseguibile (se si
vuole)
Linguaggi dinamici – A.A. 2009/2010
2
3. Ciclo di vita di un programma Perl
Linguaggi dinamici – A.A. 2009/2010
3
4. Compilazione
„ L'obiettivo della compilazione è quello di
produrre una rappresentazione del codice
sorgente in grado di essere eseguita da un
interprete
te p ete
„ L'interprete è in grado di eseguire comandi
primitivi (detti opcode) in una ben specifica
sequenza
„ La rappresentazione finale deve raggiungere
due obiettivi:
„ elencare gli opcode
l li d
„ elencare l'ordine di sequenza
Linguaggi dinamici – A.A. 2009/2010
4
5. Compilazione
„ La rappresentazione scelta è l‘Abstract Syntax
Tree (AST) un albero in cui:
(AST),
„ ogni nodo non foglia è un opcode interno del
Perl (eseguibile direttamente dall'interprete)
dall interprete)
„ ogni nodo foglia è un operando
„ l'ordine
l' di di visita (la precedenza degli operatori)
i it (l d d li t i)
è da sinistra verso destra e dal basso verso
l altro
l'altro
„ Visita in post-ordine: prima il sottoalbero
sinistro, poi quello destro, poi il nodo radice
i i t i ll d t i d di
Linguaggi dinamici – A.A. 2009/2010
5
7. Compilazione
„ Durante la fase di compilazione
„ può essere eseguito codice del programma!
„ Blocchi di codice contrassegnati con la
parola chiave BEGIN sono i t
l hi BEGIN: interpretati subito
t ti bit
dopo la loro scansione
„ Direttiva
Di tti use per il caricamento dei moduli: è
i t d i d li
interpretata subito dopo la sua scansione
„ possono essere valutate espressioni!
„ Definizioni di costanti
Linguaggi dinamici – A.A. 2009/2010
7
8. Compilazione
„ Viene effettuata una analisi sintattica completa
del programma, per determinare la presenza di
programma
eventuali errori di sintassi
„ Se viene trovato un errore di sintassi, il
sintassi
compilatore non si ferma subito (!), bensì
continua l'analisi per scovare altri errori
l analisi
„ Tipicamente, un errore sintattico ne provoca
altri in cascata
„ Dopo dieci errori, il compilatore si ferma
Linguaggi dinamici – A.A. 2009/2010
8
9. Compilazione
„ L'analisi sintattica avviene tramite l'uso di tre
moduli distinti
„ Lexer: identifica i token all'interno del codice
sorgente
„ Parser: prova ad associare un gruppo
contiguo di token ad un costrutto
ti t k d t tt
(espressione, statement) in base alla
grammatica del Perl
ti d l P l
„ Optimizer: riordina e riduce i costrutti prodotti
dal parser, con l'obiettivo di produrre
sequenze di codice equivalenti e più efficienti
Linguaggi dinamici – A.A. 2009/2010
9
10. Compilazione
„ Le fasi dell'analisi sintattica non sono
consecutive,
consecutive bensì interallacciate
„ Alcuni esempi
„ Il lexer ha bisogno di alcuni suggerimenti da
l h bi l i i ti d
parte del parser per capire come estrarre un
token
„ L'optimizer spesso non può entrare in azione
fino a quando il parser non ha raggiunto un
certo punto (elaborazione di una espressione, di
uno statement, di un blocco di una subroutine)
statement blocco,
„ Similitudine con il linguaggio naturale
Linguaggi dinamici – A.A. 2009/2010
10
11. Compilazione
„ Le fasi di analisi sintattica si alternano nel
modo seguente, con una modalità di
seguente
compilazione multi-passo
„ Passo 1: Bottom-Up Parsing
„ Il parser riceve in ingresso i token prodotti dal
lexer ed usa yacc per costruire l AST
l'AST
„ Il parsing è di tipo “bottom-up” perché parte
dalle foglie ed arriva fino alla radice dell'AST
„ In seguito alla costruzione di un nodo, si
verifica se la semantica dell'opcode relativo è
ifi l ti d ll' d l ti
congruente (ad es., se viene usato il numero ed
il tipo corretto di parametri per una funzione)
Linguaggi dinamici – A.A. 2009/2010
11
12. Compilazione
„ Le fasi di analisi sintattica si alternano nel
modo seguente, con una modalità di
seguente
compilazione multi-passo
„ Passo 1: Bottom-Up Parsing
„ Man mano che vengono costruiti sottoalberi
dell AST,
dell'AST si invoca l'optimizer per produrre
l optimizer
porzioni di statement più efficienti
„ Se il parser capisce che lo statement attuale
è una chiamata ad una funzione con un
numero di parametri fisso allora si può non
fisso,
considerare l'opcode che gestisce le funzioni
con numero di parametri variabile
Linguaggi dinamici – A.A. 2009/2010
12
13. Compilazione
„ Le fasi di analisi sintattica si alternano nel
modo seguente, con una modalità di
seguente
compilazione multi-passo
„ Passo 1: Bottom-Up Parsing
„ Non appena un sottoalbero dell'AST è generato,
viene creata una struttura ciclica che collega i
nodi dell'AST secondo l'ordinamento visto in
precedenza
„ Il nodo radice viene collegato con il primo nodo
da visitare; il primo nodo da visitare viene
collegato con il secondo nodo da visitare
Linguaggi dinamici – A.A. 2009/2010
13
14. Compilazione
„ Le fasi di analisi sintattica si alternano nel
modo seguente, con una modalità di
seguente
compilazione multi-passo
„ Passo 1: Bottom-Up Parsing
„ Quando il sottoalbero dell'AST viene attaccato
ad un altro AST il ciclo radice primo nodo si
AST, radice-primo
spezza, e viene ricostruito con il nuovo albero
„ L'interprete può individuare in maniera
efficiente (O(1)) il nodo iniziale della visita
Linguaggi dinamici – A.A. 2009/2010
14
16. Compilazione
„ Le fasi di analisi sintattica si alternano nel
modo seguente, con una modalità di
seguente
compilazione multi-passo
„ Passo 2: Top-down Optimizer
„ Non appena un sottoalbero dell'AST viene
prodotto,
prodotto viene scandito dalla radice alle foglie
per eventuali ottimizzazioni
Linguaggi dinamici – A.A. 2009/2010
16
17. Compilazione
„ Le fasi di analisi sintattica si alternano nel
modo seguente, con una modalità di
seguente
compilazione multi-passo
„ Passo 3: Peephole Optimizer
„ Alcune porzioni di codice hanno un loro spazio
di memorizzazione locale per le variabili
„ Singole Subroutine (variabili locali)
„ Si
Singoli file (variabili globali)
li fil ( i bili l b li)
„ Stringhe contenenti codice (eval())
Linguaggi dinamici – A.A. 2009/2010
17
18. Compilazione
„ Le fasi di analisi sintattica si alternano nel
modo seguente, con una modalità di
seguente
compilazione multi-passo
„ Passo 3: Peephole Optimizer
„ Il peephole optimizer ottimizza tali porzioni di
codice in maniera sequenziale
„ Controlla se esiste codice non raggiungibile
(lo cancella, in tal caso)
cancella
„ Controlla se una funzione è invocata prima
che il suo prototipo sia stato compilato
„ Cerca di risolvere le espressioni costanti il
più presto possibile (Constant f ldi )
iù t ibil (C t t folding)
Linguaggi dinamici – A.A. 2009/2010
18
19. Compilazione
„ Constant folding: l'ottimizzatore trova
operazioni con operandi tutti costanti, calcola
costanti
l'espressione finale e sostituisce
all espressione
all'espressione di partenza il suo risultato
„ Per operando si intende anche il valore di
ritorno di una funzione!
„ Ad esempo, se nell'AST di esempio si
sostituiscono a $b e $c due espressioni
costanti qualunque, tali che il risultato della
valutazione del sottoalbero AST con radice
pari al nodo 4 sia -42, si ottiene il seguente
AST ottimizzato equivalente
Linguaggi dinamici – A.A. 2009/2010
19
21. Compilazione
ƒ Strength reduction: rimpiazza operazioni
“lente” con operazioni equivalenti e più veloci
lente
ƒ Esempio:
ƒ mul ax,2 Æ shift_left ax
ƒ Null sequences: elimina operazioni inutili
ƒ Esempio:
ƒ mov r0 i; mov i r0 Æ mov r0 i
r0, i, r0,
Linguaggi dinamici – A.A. 2009/2010
21
22. Compilazione
ƒ Combine Operations: rimpiazza un insieme di
operazioni con una operazione singola
equivalente
ƒ Al b i L
Algebraic Laws: usa l leggi algebriche per
i l bi h
semplificare o riordinare le istruzioni
ƒ Special Case Instructions: usa istruzioni
“speciali” progettate per specifici operandi
Linguaggi dinamici – A.A. 2009/2010
22
23. Compilazione
„ A questo punto, la compilazione è terminata
„ Si può inspezionare l'AST prodotto con il
comando perl -MO=Concise,-src file.pl
„ Se si era invocato il servizio di controllo
sintattico del programma (perl -c source.pl), il
compilatore ci informa del risultato dell'analisi
sintattica
„ Altrimenti, si passa allo stadio successivo, che
nella nostra trattazione limitata è l'interprete
„ Ma può anche essere un altro compilatore
(p
(perlcc -o hello hello.pl)
p)
Linguaggi dinamici – A.A. 2009/2010
23
24. Interprete
„ L'interprete Perl esegue gli opcode dell'AST
nella sequenza specificata
„ L'interprete usa una macchina basata su stack
per eseguire il codice
„ Gli opcode manipolano gli operandi che
vengono i inseriti nello stack, secondo una
iti ll t k d
modalità molto simile alla notazione polacca
inversa
„ Push a, Push b
„ Opcode (pop a, pop b, calcolo, push risultato)
Linguaggi dinamici – A.A. 2009/2010
24
25. Interprete
„ L'interprete Perl crea diversi stack, fra gli altri:
„ Operand stack: memorizzazione degli operandi
degli operatori
„ Save stack: memorizzazione delle variabili il cui
S t k i i d ll i bili i
scope è stato alterato da altre
„ E
Es.: variabile globale i il cui valore è stato
i bil l b l i, i l t t
offuscato dalla variabile locale i all'interno di
una funzione
„ Return stack: memorizzazione degli indirizzi di
ritorno delle funzioni
Linguaggi dinamici – A.A. 2009/2010
25