The Ptolemy GroupUniversity of California at Berkeley
Jörn W. Janneck
Actors, actor composition, and an actor language
describing the semantics of (some) visual languages
Jörn W. Janneck
The Ptolemy GroupUniversity of California at Berkeley
2The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
credits
Johan Eker, Lund University– language design, C code generation
Yang Zhao, UCB– action-level scheduling
Chris Chang, UCB– type system, program transformations
Lars Wernli, ETH Zurich– Java code generation, generic code generation infrastructure
3The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
What's an actor?
entity that has ...– state
– ports
... and is defined by ...– outputs in response to inputs
– state transition in response to inputs
data packaged into tokens
4The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
input ports output ports
parameters
Actortokens
‘C’
31
‘L’ ‘A’
tokens
42
‘P’
99 12 ‘\’
state 42
Actors decouple data and control
N
Data
41
FIRE
What's an actor?
5The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Actors decouple data and control
input ports output ports
parameters
Actortoken
1
tokens
2
‘P’
99 12 ‘\’
state 45
N
Data
445 4142
‘C’‘A’‘L’
What's an actor?
6The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
networks of actors
actors are usually composed with other actors into networks conceptually concurrent What does a network mean?
– model of computation (coordination model)
model of computation defines– meaning of connections– 'sequence' of actor firings– state transition
A
CB
7The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
actors and visual languages
actor networks are often represented using visual languages
actor models of computation natural match for (many) VL semantics
8The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
specifying VL semantics
1. semantics of an actor• define an actor syntax first!
• then describe what it means
2. semantics of an actor composition• again, syntax first
• composition operatoractors + network actor
• the composition operator is the model of computation!
9The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
semantics of actor compositions
the operational approach– describe a generic abstract machine
– actors are 'machines' that interact with their generic environment
– a special instance of that environment is a model of computation
– examples: Ptolemy, Metropolis
two issues:– generic machine needs to anticipate the facilities needed by models of
computation
– actors become specific to models of computation
10The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
operational actor interpretation
examples:
– the Kahn process story
– the CSP story
Adder1
2
A
B
3S
11The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
semantics of actor composition
the language approach– consider an actor description a constraint on all possible behaviors
models of computation compose those descriptions– they may interpret an actor specification
– thereby adding constraints to it, specializing it
actor Adder () Double A, Double B ==> Double S:
action [a], [b] ==> [a + b] endend
12The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
What is CAL?
CAL is a (textual) language for writing actors.
supports a variety of platforms and models of computation– by supporting a variety of interpretations
– by proserving lots of static structure in the actor description» token rates
» dependencies
designed as a domain-specific language– it is intentionally incomplete
part of the Ptolemy project
13The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
a simple example
actor A (Double k) Double Input1, Double Input2 ==> Double Output:
action [a], [b] ==> [k * (a + b)] endend
14The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
another example
actor B () Double Input ==> Double Output:
Integer n := 0; Double sum := 0;
action [a] ==> [sum / n] do n := n + 1; sum := sum + a; endend
15The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
the CAL vision
provide flexible platform for expressing a wide range of actor functionality
generate (operational) implementations for specific platforms– Ptolemy/Java, C, Moses, ...
– bridge between modeling environments and implementation
serve as platform for composing actors– express models of computation as syntactic transformations in CAL
– this makes models of computation portable to any CAL platform!
profiles for portability
16The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Some language features
17The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
multiple actions, action conditions
actor C () Double Input ==> Double Output:
action [a] ==> [a] guard a >= 0 end
action [a] ==> [-a] guard a < 0 endend
actor D () Double Input ==> Double Output:
action [a] ==> [abs(a)] endend
18The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
nondeterminism
• More than one action may be firable.• Caltrop does not specify how this is resolved.• It allows deterministic as well as non-deterministic
implementations.• Often, determinism can be ascertained statically.
actor E () Double Input ==> Double Output:
action [a] ==> [a] end
action [a] ==> [-a] endend
19The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
port patterns
actor PairwiseSwap [T] () T Input ==> T Output:
action [a, b] ==> [b, a] endend
examples– [a, b, c]– [a, b, c | s]– [| s]
20The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
repeated patterns
actor ReversePrefix [T] (Integer n) T Input ==> T Output:
action [a] repeat n ==> [reverse(a)] repeat n endend
21The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
multiports, channel selectors
actor Switch [T] () multi T Data, Integer Select ==> T Output:
action [a] i, [i] ==> [a] endend
22The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
port tags
actor Switch [T] () multi T Data, Integer Select ==> T Output:
action Data: [a] i, Select: [i] ==> [a] endend
actor Switch [T] () multi T Data, Integer Select ==> T Output:
action Select: [i], Data: [a] i ==> [a] endend
23The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
action tags, action selectors
actor FairMerge [T] () T Input1, T Input2 ==> T Output:
A: action Input1: [a] ==> [a] end
B: action Input2: [a] ==> [a] end
selector (AB)* endend
other selectors are conceivable, e.g.• (AB)* | (BA)*• ( (AB) | (BA) )*
24The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
action conditions, state
actor FairMerge [T] () T Input1, T Input2 ==> T Output:
Integer s := 1;
action Input1: [a] ==> [a] guard s = 1 do s := 2; end
action Input2: [a] ==> [a] guard s = 2 do s := 1; endend
25The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
CAL
CalCore
CAL(0)
CAL(n)
parsing
CAL(1)
transformation,annotationcode generation
source text
Caltrop AST
targetplatform
Ptolemy II MosesPålsjö/Koala JGrafChartLegOS
Java platforms
C platforms
CAL compilation—the big picture.
26The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
CALCORE
Pt/Java(UCB)
Palsjo/Koala(Lund)
JGrafChart(Lund)
generic Java
generic C
LegOS(UCB)
Moses(ETH)
code generation infrastructure
27The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
A
CB
CAL composition CAL
CAL
CAL
CAL
code
genera
tion
direct codegeneration
CAL actor composition
28The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
project status We have...
– the language definition» including an informal semantics
– Java code generator» generic + Ptolemy
» usable, but not complete
» ongoing work on porting Ptolemy actor library
– C code generator» generic + Palsjo
» usable, but not complete
» Lund University uses it for writing control software for robot
» Swedish company wants to use the language for writing DSP applications
– some work on static scheduling of actor networks
– some work on actor composition
29The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
project status
We would like...– formal actor semantics
– composition and composition language
– more extensive code generation» more complete
» more platforms
» more languages
» larger function libraries
– larger actor libraries
... but most of all ...
Collaborators!
30The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Thanks.
www.gigascale.org/caltrop
31The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
32The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Motivation
Writing simple actors should be simple.
But: The Ptolemy API is very rich, and writing actors in it requires considerable skill.
However: Many Ptolemy actors have considerable commonalities - they are written in a stylized format.
33The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Motivation
We should generate many actors from a more abstract description.
Benefits:– reduces amount of code to be written
– makes writing actors more accessible
– reduces error probability
– makes code more versatile» actors may be retargeted to other platforms, or new versions of the Ptolemy
API
34The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Overview of the implementation
general architecture
aspects of the Pt/Java implementation
35The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Caltrop implementation—the big picture.
Caltrop
CalCore
Caltrop(0)
Caltrop(n)
parsing
Caltrop(1)
transformation,annotationcode generation
source text
Caltrop AST
targetplatform
Pt/Java TinyOS/C?DSP/FPGA?Matlab? ???
split-phase CalCore
36The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Caltrop implementation many small modules
– transformers, annotaters, checkers
transforming Caltrop into some language subset
CalCore– small, semantically complete subset
– minimal language for code generation, analysis, transformation
– built on functional and procedural closures
37The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Transformers & annotators replace control structures
replace port patterns
sort variable declarations
replace operators
propagate type information
check static properties
tag port patterns
...
38The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Caltrop implementation
Benefits:– Much of the ‘hard’ stuff can be done on the same data structure,
exploiting the regularities of the Caltrop/CalCore semantics and the existing software infrastructure.
– Code generators becomes relatively small, thus making retargeting easier.
– Intermediate results are valid Caltrop programs, making debugging a lot easier.
» We can look at them easily.
» We can use the parser and the well-formedness/type checkers themselves as debugging tools!
39The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Switch in CalCore*
actor Switch [T] () multi T Data, Integer Select ==> T Output :
action Select::[|G0], Data::[|G2] all ==> Output::[a] where G1, G3 with Boolean G1 := available(G0, 1), Integer i := if G1 then G0[0] else null end, Integer G4 := i, Boolean G3 := available(G2[G4], 1), Integer a := if G3 then G2[G4][0] else null end endend
*Actually, we are cheating here; CalCore is in fact even more primitive. And even less readable...
40The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
CalCore ==> Pt/Java
different programming models– single atomic action vs prefire/firen/postfire– referentially transparent access to channels vs. token consuming read methods
– stateful computation vs state-invariant fire
41The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
CalCore ==> Pt/Java mapping Caltrop notions to Pt/Java concepts
– parameters ==> attributes + attribute changes
– types and type checking
– ...
42The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
What goes into prefire()?
actor Switch [T] () multi T Data, Integer Select ==> T Output :
action Select::[|G0], Data::[|G2] all ==> Output::[a] where G1, G3 with Boolean G1 := available(G0, 1), Integer i := if G1 then G0[0] else null end, Integer G4 := i, Boolean G3 := available(G2[G4], 1), Integer a := if G3 then G2[G4][0] else null end endend
All computation that is required in order to decide firability?Just the part of it before the first token access?
43The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
prefire/fire aggressive vs defensive condition evaluation
incrementally computing conditions
reusing computation done in prefire
Should tokens read in prefire be kept if prefire returns false?
44The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
fire/postfire
action Input1::[|G0] ==> Output::[a] where equals(s,1), G1 with Boolean G1 := available(G0, 1), T a := if G1 then G0[0] else null end : s := 2; end
action Input1:: [a] ==> [a] where s = 1 :
s := 2; end
Computation that does not affect the output can be done in postfire.
prefire
fire
postfire
45The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
State managementIf state needs to be changed in order to compute output, it needs to be shadowed.
safe state management– referentially transparent expressions
– no aliasing of stateful structures
46The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
State management
actor B () Double Input ==> Double Output:
Integer n := 0; Double sum := 0;
action [a] ==> [sum / n] : n := n + 1; sum := sum + a; endend
The division between fire and postfire can be expressedin Caltrop (btw, this is a non-CalCore transformation)using action tags and selectors.
47The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
State management
actor B () Double Input ==> Double Output:
Integer n := 0; Integer n$shadow; Double sum := 0; Double sum$shadow;
fire: action [a] ==> [sum$shadow / n$shadow] : n$shadow := n; sum$shadow := sum; n$shadow := n$shadow + 1; sum$shadow := sum$shadow + a; end
postfire: action ==> : n := n$shadow; sum := sum$shadow; end
selector (fire+ postfire)* endend
48The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Things we need to do...
49The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Short term “grunt” work well-formedness checks
type system, type checking
split-phase analyses
interpreter (+ wrapper for Pt/Java)
optimizations, big and small
other transformers, annotators
50The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Fun mid-term projects static analysis of actor properties (data rates, dependency on
state, parameters, input, ...)
relation to MoC (e.g. BDF)
computing interface automata from actor descriptions
code generators to other platforms and languages
code generation for composite actors?
51The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Even funner long-term projects generic code generation framework
– maybe based on Calif?
extending the language– higher-order constructs
– domains/directors+receivers
a formal semantics, a framework for actor analysis
52The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Caltrop resources
www.gigascale.org/caltrop
Meeting:
Tuesdays, 1:30pm,
DOP Center Library(We need Caltroopers!)
53The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Other slides
54The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
What is CAL?
CAL is a textual syntax for representing dataflow actors.
formal semantics
easily retargetable to different tools and environments
55The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
What can we do with CAL?
We can formally manipulate actor descriptions. actor transformation
code generation – to Java, C
actor composition
56The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
code generation infrastructure
CAL
CALCORE
Pt/Java(UCB)
Palsjo/Koala(Lund)
other tools
JGrafChart(Lund)
CAL(1)
CAL(n)
generic Java
generic C
LegOS(UCB)
Moses(ETH)
2.2 customize frameworks with generators
2.4 generate embedded software from models
57The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
CAL snippets
58The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Can you guess what this does?
actor A (Double k) Double Input1, Double Input2 ==> Double Output:
action [a], [b] ==> [k*(a + b)] endend
59The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Or this?
actor B () Double Input ==> Double Output:
Integer n := 0; Double sum := 0;
action [a] ==> [sum / n] : n := n + 1; sum := sum + a; endend
60The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Multiple actions, action conditions
actor C () Double Input ==> Double Output:
action [a] ==> [a] where a >= 0 end
action [a] ==> [-a] where a < 0 endend
actor D () Double Input ==> Double Output:
action [a] ==> [abs(a)] endend
61The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Nondeterminism
actor E () Double Input ==> Double Output:
action [a] ==> [a] end
action [a] ==> [-a] endend
• More than one action may be firable.• Caltrop does not specify how this is resolved.• It allows deterministic as well as non-
deterministic implementations.• Often, determinism can be ascertained
statically.
62The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Port patterns
actor PairwiseSwap [T] () T Input ==> T Output:
action [a, b] ==> [b, a] endend
examples– [a, b, c]– [a, b, c | s]– [| s]
63The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Repeated patterns
actor ReversePrefix [T] (Integer n) T Input ==> T Output:
action [a] repeat n ==> [reverse(a)] repeat n endend
64The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Channel selectors
actor Switch [T] () multi T Data, Integer Select ==> T Output:
action [a] i, [i] ==> [a] endend
65The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Action tags, action selectors
actor FairMerge [T] () T Input1, T Input2 ==> T Output:
A: action Input1:: [a] ==> [a] end
B: action Input2:: [a] ==> [a] end
selector (AB)* endend
other selectors are conceivable, e.g.• (AB)* | (BA)*• ( (AB) | (BA) )*
66The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Action conditions, state
actor FairMerge [T] () T Input1, T Input2 ==> T Output:
Integer s := 1;
action Input1:: [a] ==> [a] where s = 1: s := 2; end
action Input2:: [a] ==> [a] where s = 2: s := 1; endend
67The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Motivation
Writing simple actors should be simple. But: The Ptolemy API is very rich, and writing actors in it
requires considerable skill.
However: Many Ptolemy actors have considerable commonalities - they are written in a stylized format.
68The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
MotivationWe should generate many actors from a more abstract
description.
Benefits:– reduces amount of code to be written
– makes writing actors more accessible
– reduces error probability
– makes code more versatile» actors may be retargeted to other platforms, or new versions of the Ptolemy
API
69The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Why is Caltrop useful for me? For Ptolemy users:
– Makes it easier to write atomic actors.
– Makes Ptolemy accessible to a wider audience.
For Ptolemy ‘hackers’:– Reduces possibilities for bugs.
– Makes actors more reusable.
– Enables analysis and efficient code generation.
70The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Transformers & annotators replace control structures
replace port patterns
sort variable declarations
replace operators
propagate type information
check static properties
tag port patterns
...
71The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
CAL implementation highly modular
– transformers, annotaters, checkers
transforming Cal into some language subset
CalCore– small, semantically complete subset
– minimal language for code generation, analysis, transformation
– built on functional and procedural closures
72The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
CAL implementation
Benefits:– Much of the ‘hard’ stuff can be done on the same data structure,
exploiting the regularities of the Caltrop/CalCore semantics and the existing software infrastructure.
– Code generators becomes relatively small, thus making retargeting easier.
– Intermediate results are valid Caltrop programs, making debugging a lot easier.
» We can look at them easily.
» We can use the parser and the well-formedness/type checkers themselves as debugging tools!
73The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Port tags
actor Switch [T] () multi T Data, Integer Select ==> T Output:
action Data:: [a] i, Select:: [i] ==> [a] endend
actor Switch [T] () multi T Data, Integer Select ==> T Output:
action Select:: [i], Data:: [a] i ==> [a] endend
74The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Overview of the implementation
general architecture
aspects of the Pt/Java implementation
75The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Switch in CalCore*
actor Switch [T] () multi T Data, Integer Select ==> T Output :
action Select::[|G0], Data::[|G2] all ==> Output::[a] where G1, G3 with Boolean G1 := available(G0, 1), Integer i := if G1 then G0[0] else null end, Integer G4 := i, Boolean G3 := available(G2[G4], 1), Integer a := if G3 then G2[G4][0] else null end endend
*Actually, we are cheating here; CalCore is in fact even more primitive. And even less readable...
76The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
CalCore ==> Pt/Java
different programming models– single atomic action vs prefire/firen/postfire– referentially transparent access to channels vs. token consuming read methods
– stateful computation vs state-invariant fire
77The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
CalCore ==> Pt/Java mapping Caltrop notions to Pt/Java concepts
– parameters ==> attributes + attribute changes
– types and type checking
– ...
78The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
What goes into prefire()?
actor Switch [T] () multi T Data, Integer Select ==> T Output :
action Select::[|G0], Data::[|G2] all ==> Output::[a] where G1, G3 with Boolean G1 := available(G0, 1), Integer i := if G1 then G0[0] else null end, Integer G4 := i, Boolean G3 := available(G2[G4], 1), Integer a := if G3 then G2[G4][0] else null end endend
All computation that is required in order to decide firability?Just the part of it before the first token access?
79The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
prefire/fire aggressive vs defensive condition evaluation
incrementally computing conditions
reusing computation done in prefire
Should tokens read in prefire be kept if prefire returns false?
80The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
fire/postfire
action Input1::[|G0] ==> Output::[a] where equals(s,1), G1 with Boolean G1 := available(G0, 1), T a := if G1 then G0[0] else null end : s := 2; end
action Input1:: [a] ==> [a] where s = 1 :
s := 2; end
Computation that does not affect the output can be done in postfire.
prefire
fire
postfire
81The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
State managementIf state needs to be changed in order to compute output, it needs to be shadowed.
safe state management– referentially transparent expressions
– no aliasing of stateful structures
82The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
State management
actor B () Double Input ==> Double Output:
Integer n := 0; Double sum := 0;
action [a] ==> [sum / n] : n := n + 1; sum := sum + a; endend
The division between fire and postfire can be expressedin Caltrop (btw, this is a non-CalCore transformation)using action tags and selectors.
83The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
State management
actor B () Double Input ==> Double Output:
Integer n := 0; Integer n$shadow; Double sum := 0; Double sum$shadow;
fire: action [a] ==> [sum$shadow / n$shadow] : n$shadow := n; sum$shadow := sum; n$shadow := n$shadow + 1; sum$shadow := sum$shadow + a; end
postfire: action ==> : n := n$shadow; sum := sum$shadow; end
selector (fire+ postfire)* endend
84The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Things we need to do...
85The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Short term “grunt” work well-formedness checks
type system, type checking
split-phase analyses
interpreter (+ wrapper for Pt/Java)
optimizations, big and small
other transformers, annotators
86The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Fun mid-term projects static analysis of actor properties (data rates, dependency on
state, parameters, input, ...)
relation to MoC (e.g. BDF)
computing interface automata from actor descriptions
code generators to other platforms and languages
code generation for composite actors?
87The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Even funner long-term projects generic code generation framework
– maybe based on Calif?
extending the language– higher-order constructs
– domains/directors+receivers
a formal semantics, a framework for actor analysis
88The Ptolemy Group
University of California at BerkeleyJörn W. Janneck
Caltrop resources
www.gigascale.org/caltrop
Meeting:
Tuesdays, 1:30pm,
DOP Center Library(We need Caltroopers!)