minor rewrite
This commit is contained in:
parent
7aed0cac1a
commit
9250425a61
4 changed files with 8378 additions and 46 deletions
BIN
.DS_Store
vendored
Normal file
BIN
.DS_Store
vendored
Normal file
Binary file not shown.
|
@ -147,15 +147,7 @@ Why is recording favoured over emulation, for example? How can recorded
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Standard
|
\begin_layout Standard
|
||||||
Section 7.1 mentions a generic module to support the development of simulators.
|
Specifically:
|
||||||
Furthermore the section describes some simulators developed using the gen_fsm
|
|
||||||
behaviour.
|
|
||||||
Which additional features are provided by the software described in this
|
|
||||||
thesis, which are not already present in the gen_fsm behaviour?
|
|
||||||
\end_layout
|
|
||||||
|
|
||||||
\begin_layout Standard
|
|
||||||
In the thesis there are some unclear points:
|
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Itemize
|
\begin_layout Itemize
|
||||||
|
@ -167,6 +159,12 @@ In the thesis there are some unclear points:
|
||||||
? Also, what is the “old work flow” in this context?
|
? Also, what is the “old work flow” in this context?
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Itemize
|
||||||
|
4.2: This section states a simulation library and support for creating new
|
||||||
|
simulators.
|
||||||
|
Yet these are not explained like for example the convenience scripts.
|
||||||
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Itemize
|
\begin_layout Itemize
|
||||||
5.2: Exactly how is the quality of the simulators measured? Which metrics
|
5.2: Exactly how is the quality of the simulators measured? Which metrics
|
||||||
are used? Some metrics are presented here, but not motivated, also results
|
are used? Some metrics are presented here, but not motivated, also results
|
||||||
|
@ -174,9 +172,21 @@ In the thesis there are some unclear points:
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Itemize
|
\begin_layout Itemize
|
||||||
4.2: This section states a simulation library and support for creating new
|
7.1: mentions a generic module to support the development of simulators.
|
||||||
simulators.
|
Furthermore the section describes some simulators developed using the gen_fsm
|
||||||
Yet these are not explained like for example the convenience scripts.
|
behaviour.
|
||||||
|
Which additional features are provided by the software described in this
|
||||||
|
thesis, which are not already present in the gen_fsm behaviour?
|
||||||
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Itemize
|
||||||
|
According to 7.4, API:s and simulators must be created when they don't already
|
||||||
|
exist, why is this not represented in the first flow chart? Does your applicati
|
||||||
|
on provide any ways to reduce development time of simulators? The quality
|
||||||
|
of a simulator may vary..
|
||||||
|
You created three simple device simulators.
|
||||||
|
How long did it take to create them? Case studies of developing these could
|
||||||
|
motivate the usage of simulators over hardware.
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Standard
|
\begin_layout Standard
|
||||||
|
@ -185,13 +195,6 @@ A future improvement to the project is creating a finite state machine from
|
||||||
It is unclear to us how this improves the system.
|
It is unclear to us how this improves the system.
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Standard
|
|
||||||
A future improvement of the system is to implement “runtime function call
|
|
||||||
replacement”, this directly contradicts the purpose of the thesis, which
|
|
||||||
is to run the same code on both the simulator and the real hardware.
|
|
||||||
Why is this considered to be an improvement?
|
|
||||||
\end_layout
|
|
||||||
|
|
||||||
\begin_layout Standard
|
\begin_layout Standard
|
||||||
Also, there are some factual errors; processes do share data, and data is
|
Also, there are some factual errors; processes do share data, and data is
|
||||||
shared through message passing.
|
shared through message passing.
|
||||||
|
@ -200,11 +203,6 @@ Also, there are some factual errors; processes do share data, and data is
|
||||||
PIDs can indeed be converted to lists, using the pid_to_list/1 function.
|
PIDs can indeed be converted to lists, using the pid_to_list/1 function.
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Standard
|
|
||||||
7.5.1 says that ember can automate the process of deploying code.
|
|
||||||
How is this useful? What sort of code?
|
|
||||||
\end_layout
|
|
||||||
|
|
||||||
\begin_layout Section*
|
\begin_layout Section*
|
||||||
Results
|
Results
|
||||||
\end_layout
|
\end_layout
|
||||||
|
@ -233,18 +231,28 @@ How long does it take to upload the code to the hardware and how often is
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Itemize
|
\begin_layout Itemize
|
||||||
How long, on the other hand, does it take to get to know your system, write
|
How long does it take to get to know your system, write the simulators and
|
||||||
the simulators and follow the steps you described?
|
follow the steps you described? Is the workflow more efficient using your
|
||||||
|
system?
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Itemize
|
\begin_layout Itemize
|
||||||
Did you calculate a difference of time between the two approaches?
|
Did you calculate a difference of time between development on the hardware
|
||||||
|
versus in a simulated environment?
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Standard
|
\begin_layout Standard
|
||||||
The graphs provided are inconclusive and lack good descriptive texts.
|
The graphs provided are inconclusive and lack good descriptive texts.
|
||||||
It is unclear which metrics are used on each axis, and exactly what is
|
It is unclear which metrics are used on each axis, and exactly what is
|
||||||
being measured; for instance, what is a sample?
|
being measured; for instance, what is a
|
||||||
|
\begin_inset Quotes eld
|
||||||
|
\end_inset
|
||||||
|
|
||||||
|
sample
|
||||||
|
\begin_inset Quotes erd
|
||||||
|
\end_inset
|
||||||
|
|
||||||
|
?
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Standard
|
\begin_layout Standard
|
||||||
|
@ -254,21 +262,6 @@ The accuracy of the simulators was presented in a graph, and it can be seen
|
||||||
impacts does this have on the simulation?
|
impacts does this have on the simulation?
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Standard
|
|
||||||
According to 7.4, API:s and simulators must be created when they don't already
|
|
||||||
exist.
|
|
||||||
Isn't it a huge project within itself, creating an API:s and simulators?
|
|
||||||
Does your application provide any ways to reduce development time of simulators
|
|
||||||
? The quality of a simulator may vary.
|
|
||||||
There may take a long time to make it perform well and be flexible to work
|
|
||||||
with.
|
|
||||||
You created three simple device simulators.
|
|
||||||
How long did it take to create them? These times could prove why the developmen
|
|
||||||
t of simulators wouldn't be a great deal and to estimate creation time of
|
|
||||||
other simulators.
|
|
||||||
|
|
||||||
\end_layout
|
|
||||||
|
|
||||||
\begin_layout Section*
|
\begin_layout Section*
|
||||||
Language
|
Language
|
||||||
\end_layout
|
\end_layout
|
||||||
|
@ -283,23 +276,27 @@ The language style in the thesis is not formal as it would be expected in
|
||||||
\begin_layout Standard
|
\begin_layout Standard
|
||||||
Some terms could be introduced better; OTP, Beagle Board, Gumstix, Ångström/Angs
|
Some terms could be introduced better; OTP, Beagle Board, Gumstix, Ångström/Angs
|
||||||
trom, distro, NAT, OS, Panda Board, VM, stub, public/subscribe, request-response
|
trom, distro, NAT, OS, Panda Board, VM, stub, public/subscribe, request-response
|
||||||
, OS variable, ssh.
|
, OS variable and SSH.
|
||||||
Erlang is introduced properly, and the same could perhaps be done for these
|
Erlang is introduced properly, and the same could perhaps be done for these
|
||||||
terms as well.
|
terms as well.
|
||||||
The structure of function calls (fun/num of pars) is not obvious to the
|
The structure of function calls (fun/num of pars) is not obvious to the
|
||||||
reader, perhaps it could be explained.
|
reader, perhaps it could be explained.
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
|
\begin_layout Standard
|
||||||
|
It is hard to refer to the figures since they are not numbered.
|
||||||
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Section*
|
\begin_layout Section*
|
||||||
What we would like to see ...
|
What we would like to see ...
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
\begin_layout Standard
|
\begin_layout Standard
|
||||||
It would be interesting to see this system combined with a testing framework,
|
It would be interesting to see this system combined with a testing framework,
|
||||||
like QuickCheck in order to create a powerful test suite which generates
|
like QuickCheck, in order to create a powerful test suite which generates
|
||||||
tests using real data samples.
|
tests using real data samples.
|
||||||
If the data generated by the recorder could be used as input to a testing
|
If the data generated by the recorder could be used as input to a testing
|
||||||
framework, like QuickCheck a very powerful and random test suite could
|
framework, like QuickCheck, a very powerful and random test suite could
|
||||||
be created.
|
be created.
|
||||||
\end_layout
|
\end_layout
|
||||||
|
|
||||||
|
|
BIN
report2.pdf
Normal file
BIN
report2.pdf
Normal file
Binary file not shown.
8335
report_commented.lyx
Normal file
8335
report_commented.lyx
Normal file
File diff suppressed because it is too large
Load diff
Loading…
Add table
Add a link
Reference in a new issue