It is so difficult to cancel an execution in GUI written in OCaml.
To cancel a long program run in Acumen GUI, it seems that I have the following problems:
(1) If using singe thread, a "cancel" signal will be pended until current (long) computation is completed, which makes it potentially useless.
(2) Thread is so inconvenient to use in OCaml! There are several problems:
First, if using "fork", it turns out to be that I cannot update the GUI from within my callback thread. In practice, no thread other than the main thread (aka "GUI-thread") may update any widget (that is, no call to QWidget::update(), QWidget::setFoo() etc. from another thread).
So I tried the following: In my worker thread put events into the Qt event queue and inform the GUI thread that it needs to update its GUI state according to the "model" (that is, my sound data). But things are still messed up, and eventually, "Unix.kill" or "Thread.kill" are neither implemented in OCaml!
(3) I solved the problem by a somehow nasty trick:
I break my mega computation into something that can get done in pieces and have [eval prog1] return true or false based on whether it has more work to do. Then schedule it using [Idle.add], and it'll keep running in chunks until it's done, but the GUI will still get time to process events (and allow you to kill the task by removing it from the idle loop).
Tuesday, February 26, 2008
Wednesday, February 20, 2008
Problem with Threads in GUI
When trying to implement a GUI, I tried to create a new thread on pressing
the "execute" button, However, I got the following errors:
The problem turned out to be that I update the GUI from within my callback thread. In practice, no thread other than the main thread (aka "GUI-thread") may update any widget (that is, no call to QWidget::update(), QWidget::setFoo() etc. from another thread).
What can I do to solve the problem? I can try the following:
In my worker thread put events into the Qt event queue and inform the GUI thread that it needs to update its GUI state according to the "model" (that is, your sound data).
See QApplication::postEvent. This is a common mistake, see also Qt archive for more details. Maybe qtforum.org knows more as well (haven't checked).
the "execute" button, However, I got the following errors:
Xlib: unexpected async reply (sequence 0x4fc8)!
The problem turned out to be that I update the GUI from within my callback thread. In practice, no thread other than the main thread (aka "GUI-thread") may update any widget (that is, no call to QWidget::update(), QWidget::setFoo() etc. from another thread).
What can I do to solve the problem? I can try the following:
In my worker thread put events into the Qt event queue and inform the GUI thread that it needs to update its GUI state according to the "model" (that is, your sound data).
See QApplication::postEvent. This is a common mistake, see also Qt archive for more details. Maybe qtforum.org knows more as well (haven't checked).
Thursday, February 14, 2008
Drawing Surface Function [TODO]
(1) How to draw now:
To plot a 1-D surface function
f(x) = sin(x)
You can use:
external matlab
reads surface_line;
system
f(x) = sin(x);
surface_line = f(t);
To plot a 2-D surface function
x+y=0, you should treat x as t and
define y in terms of x, so you get y = f(x),
Then use above method to draw it.
Or you can parameterize both x, and y with another z
func_x (x) = sin(x);
func_y (y) = cos(y);
then define
x_curve = func_x(t);
y_curve = func_y(t);
in matlab reads x_curve, and y_curve.
(2) Problem:
"This will work around the derivative issue and the code appears to work fine, but now I am unable to plot the surface that the vehicle traverses, because it is a function. Is there some way to do this? It would be helpful if once I have more complex surfaces I can see the surface and the system's response to the surface together on the plot. Thanks."
"I agree that this will work, but it regresses back to what I had for the implementation before this. Before I could create a function, I had to individually create each track along the surface in terms of t. If you look at 2DofSpringDamper-4Wheel-Surface.phydl on my Wiki page, that is what I did there - after individually calculating each line along the surface in terms of t, I could plot them. However, this is not the ideal way to do things. Assuming a more complex system, or one where there are more than four objects tracking along a surface, it can become quite tedious to calculate each individually, and ideally the software should be able to do it for you. This was the whole point of adding functions in the first place - so that you dont have to calculate each function. Which worked (see 2DofSpringDamper-4Wheel-Surface2.phydl, allowing for modifications for derivative of function), but then its not helpful if you have to calculate each function anyway again to plot.
Basically, while I agree that this will work around the problem, it is a step backwards, and I think that there is some better way to fix the problem. Everyone please let me know what they think."
-Kevin
(3) Comments:
"the problem is that Kevin would like to render a multi-parameter function (the surface), and we are only letting it pass to the outside world as a single parameter function. This seems like a particularly enlightening situation, because it points out a limitation of the current way in which we are doing "external": We are assuming that all external interactions with the outside world are simple values that are functions of times. This is certainly a very useful thing to have, but it is not the only kind of thing that we'd like to have in external with the outside world. When we are working on real problems in Acumen and we are modeling a complex physical
environment, this model will have complex constants that are basically functions, and we will want to have a good way to pass such functions back and forth with the outside
tools."
"[TO Angela]: In some sense, we can already achieve this with the current external mechanism. Basically, if we want to export a function f:A -> B we can export it
as (lambda (t) f) : T -> A -> B, which is a function that just ignores time. The only problem, of course, is that the user on the other side is likely to recompute this function many times on the other side. of course, we also have to have function spaces in our co-domain. An alternative way that might be worth trying is to allow a new syntactic form "reads constant ..." and "writes constant ..." which basically does the trick that we are talking about above implicitly, and could possibly make it easier for outside programs to recognize this situation."
-Walid
To plot a 1-D surface function
f(x) = sin(x)
You can use:
external matlab
reads surface_line;
system
f(x) = sin(x);
surface_line = f(t);
To plot a 2-D surface function
x+y=0, you should treat x as t and
define y in terms of x, so you get y = f(x),
Then use above method to draw it.
Or you can parameterize both x, and y with another z
func_x (x) = sin(x);
func_y (y) = cos(y);
then define
x_curve = func_x(t);
y_curve = func_y(t);
in matlab reads x_curve, and y_curve.
(2) Problem:
"This will work around the derivative issue and the code appears to work fine, but now I am unable to plot the surface that the vehicle traverses, because it is a function. Is there some way to do this? It would be helpful if once I have more complex surfaces I can see the surface and the system's response to the surface together on the plot. Thanks."
"I agree that this will work, but it regresses back to what I had for the implementation before this. Before I could create a function, I had to individually create each track along the surface in terms of t. If you look at 2DofSpringDamper-4Wheel-Surface.phydl on my Wiki page, that is what I did there - after individually calculating each line along the surface in terms of t, I could plot them. However, this is not the ideal way to do things. Assuming a more complex system, or one where there are more than four objects tracking along a surface, it can become quite tedious to calculate each individually, and ideally the software should be able to do it for you. This was the whole point of adding functions in the first place - so that you dont have to calculate each function. Which worked (see 2DofSpringDamper-4Wheel-Surface2.phydl, allowing for modifications for derivative of function), but then its not helpful if you have to calculate each function anyway again to plot.
Basically, while I agree that this will work around the problem, it is a step backwards, and I think that there is some better way to fix the problem. Everyone please let me know what they think."
-Kevin
(3) Comments:
"the problem is that Kevin would like to render a multi-parameter function (the surface), and we are only letting it pass to the outside world as a single parameter function. This seems like a particularly enlightening situation, because it points out a limitation of the current way in which we are doing "external": We are assuming that all external interactions with the outside world are simple values that are functions of times. This is certainly a very useful thing to have, but it is not the only kind of thing that we'd like to have in external with the outside world. When we are working on real problems in Acumen and we are modeling a complex physical
environment, this model will have complex constants that are basically functions, and we will want to have a good way to pass such functions back and forth with the outside
tools."
"[TO Angela]: In some sense, we can already achieve this with the current external mechanism. Basically, if we want to export a function f:A -> B we can export it
as (lambda (t) f) : T -> A -> B, which is a function that just ignores time. The only problem, of course, is that the user on the other side is likely to recompute this function many times on the other side. of course, we also have to have function spaces in our co-domain. An alternative way that might be worth trying is to allow a new syntactic form "reads constant ..." and "writes constant ..." which basically does the trick that we are talking about above implicitly, and could possibly make it easier for outside programs to recognize this situation."
-Walid
Acumen [TODO]
For the paper:
(1) the formal definition of normalization,
(2) the formal semantics,
(3) a clear statement of the theorem(s) that you have,
(4) the proof that you have.
For the implementation:
(1) About Equation Format
I don't like the fact that the equations in PhyDL have (1/m1 * ...). In particular, this introduces division, which the original system did not have. Also, it is notationally different (and heavier) than the original system. Can we extend pre-processing to allow constant factors on the left-hand-side?
In the future, also, I would like us to explore more general questions, where, for example, we can always simply write equations in the form "0 = ...", which is how engineers generally write their force equations.
(2) About Precision
I (and an CS/PL reader would) see from this example is that the simulation parameter suggest that you probably don't provide very strong guarantees about accuracy. In particular, the fact that you specify a step-size suggests that this is a low-level specification for a simulation. When we are finally doing high-fidelity simulation, I would expect to see that a simulation run is specified in terms of the accuracy of the result, not how the engineer thinks the simulation ought to be run.
(1) the formal definition of normalization,
(2) the formal semantics,
(3) a clear statement of the theorem(s) that you have,
(4) the proof that you have.
For the implementation:
(1) About Equation Format
I don't like the fact that the equations in PhyDL have (1/m1 * ...). In particular, this introduces division, which the original system did not have. Also, it is notationally different (and heavier) than the original system. Can we extend pre-processing to allow constant factors on the left-hand-side?
In the future, also, I would like us to explore more general questions, where, for example, we can always simply write equations in the form "0 = ...", which is how engineers generally write their force equations.
(2) About Precision
I (and an CS/PL reader would) see from this example is that the simulation parameter suggest that you probably don't provide very strong guarantees about accuracy. In particular, the fact that you specify a step-size suggests that this is a low-level specification for a simulation. When we are finally doing high-fidelity simulation, I would expect to see that a simulation run is specified in terms of the accuracy of the result, not how the engineer thinks the simulation ought to be run.
Programming in Concoqtion [DONE]
- Instead of focusing on two data-structures, we should really focus
on concepts. In fact, it would be better to start directly with saying
that we want to focus on the four programming techniques (existentials,
option types, match, and cast) and THEN saying that they will
be illustrated with examples using lists and braun trees.
- Note: We should write this section in the context of what was
already discussed in the paper. For example, where lists not
discussed at all?
- Also, the definitions of sized lists and braun trees can be
explain in section 1. We can drop the current intro/opening
of section 2. Also, it would be good to write each example
on a different line, so that they come up something like this:
Nil : (0, 'a) list
Cons (1, Nil) : (1, int) list
Cons ('a', Cons 'b', Nil) : (2, char) list
with the semi-colons aligned one on top of the other.
- For the braun trees, it might be good to insert some little
diagrams. If you want to do that, then it it would be good
to look for some latex packages for drawing small trees.
Alternatively, you can generate a high-quality pdf using an
easily available program, and we can include it in the tex
file. Generally, the first option is preferable.
- A section on existential quantification should explain in
broader terms why it would be needed in general. First, it
should start with a clear statement: While we have an explicit
construct for universal quantification at the level of types,
we do not have one for existential quantification.
Existential quantification arises natural in situations where
a function (such as a type-checker) has to produce a value with
a type that was not explicitly provided in the input.
In fact, existentials would be needed whenever we have coercsions
from values of simple types to values of more refined depedent
types (such as converting from lists to sized lists). It is
therefore
important to know how to Concoqtion can express a limited
for of existentials. The basic idea is drawn from the following
relation between existential and universal quantification:
... write equivalence here ...
- Is it really necessary to understand how things work in Coq
to understand this trick? We should keep everything as short
and as direct as possible.
on concepts. In fact, it would be better to start directly with saying
that we want to focus on the four programming techniques (existentials,
option types, match, and cast) and THEN saying that they will
be illustrated with examples using lists and braun trees.
- Note: We should write this section in the context of what was
already discussed in the paper. For example, where lists not
discussed at all?
- Also, the definitions of sized lists and braun trees can be
explain in section 1. We can drop the current intro/opening
of section 2. Also, it would be good to write each example
on a different line, so that they come up something like this:
Nil : (0, 'a) list
Cons (1, Nil) : (1, int) list
Cons ('a', Cons 'b', Nil) : (2, char) list
with the semi-colons aligned one on top of the other.
- For the braun trees, it might be good to insert some little
diagrams. If you want to do that, then it it would be good
to look for some latex packages for drawing small trees.
Alternatively, you can generate a high-quality pdf using an
easily available program, and we can include it in the tex
file. Generally, the first option is preferable.
- A section on existential quantification should explain in
broader terms why it would be needed in general. First, it
should start with a clear statement: While we have an explicit
construct for universal quantification at the level of types,
we do not have one for existential quantification.
Existential quantification arises natural in situations where
a function (such as a type-checker) has to produce a value with
a type that was not explicitly provided in the input.
In fact, existentials would be needed whenever we have coercsions
from values of simple types to values of more refined depedent
types (such as converting from lists to sized lists). It is
therefore
important to know how to Concoqtion can express a limited
for of existentials. The basic idea is drawn from the following
relation between existential and universal quantification:
... write equivalence here ...
- Is it really necessary to understand how things work in Coq
to understand this trick? We should keep everything as short
and as direct as possible.
Related Work [TODO]
The current document features six slides. The first two slides try
to explain and distinguish between operational and denotational
semantics. Next, the slides try to explain some problems with
each of these two approaches. This is followed by a surprising
brief discussion of a surprisingly small number of papers.
Things that are needed:
-At the very beginning, give a clear description of your own work.
This is necessary here, because this is a stand alone document.
A very important part of this will be a clear statement of the
problem (or problems) that you are trying to solve. Then, the
papers that you will talk about in the related work sections will
be essentially all the papers that try to solve the same problem or
problems.
- Diagrams are fantastic, but it is absolutely essential to have
text that explains exactly what the intended meaning from each
one of these diagrams is. This kind of textual explanation should
be the rule for any kind of display (diagram, equation, table, graph,
mathematical formula, etc).
- When you start thinking about related work, you should immediately
start working on an extended "Related Work" section. Such as an
extended related work section can be thought of as an annotated
bibliography: It is a list of references, with your comment about
these references. It is useful (for you, mainly) to have your
comments about all papers that you have read. More important for
presentation to me is how you classify these papers (that is, how
you organize them into related groups) and how you explain the
relation between each of these other projects and your work.
- Vitally, you need to add specific citations. Yes, it is very
useful to explain how the literature can be divided, but it is
essential that such an explanation comes with statements about how
individual papers fall in each group. It is also especially important
that you identify both examples papers in each group as well as
the papers that you and others view as important (not necessarily
the same).
Things that need rethinking:
- Whatever classification you introduce, you should make sure that
you already know where your work falls. It might be useful for
you to make a table (similar to the one in the concoqtion paper)
as you are trying to figure out how to organize the related work.
It is OK to find that you are redoing the table several times
until you get to something that you are happy with.
- Avoid complex definitions, especially for things that are not
necessarily essential for your related work section. Examples
are the subjects of operational and denotational semantics. If
you think about what you have done, you have not really focused
on related work. Instead, you tried to explain why there are
problems with operational and denotational semantics based design.
This is not a good idea, for two reasons. First, it may not
be something that can be done very clearly. Second, it is not
essential for your goal, which is organizing the related work,
and explaining where in this context your paper falls.
- When you are doing a classification of papers, you can't do that
based on the title or the topic or what you heard about papers
or projects. You really have to read the papers carefully and
determine for yourself what you think about the extent and the
way they have managed (or not managed) to solve "The Problem(s)"
that you have identified at the beginning of your related work
section.
to explain and distinguish between operational and denotational
semantics. Next, the slides try to explain some problems with
each of these two approaches. This is followed by a surprising
brief discussion of a surprisingly small number of papers.
Things that are needed:
-At the very beginning, give a clear description of your own work.
This is necessary here, because this is a stand alone document.
A very important part of this will be a clear statement of the
problem (or problems) that you are trying to solve. Then, the
papers that you will talk about in the related work sections will
be essentially all the papers that try to solve the same problem or
problems.
- Diagrams are fantastic, but it is absolutely essential to have
text that explains exactly what the intended meaning from each
one of these diagrams is. This kind of textual explanation should
be the rule for any kind of display (diagram, equation, table, graph,
mathematical formula, etc).
- When you start thinking about related work, you should immediately
start working on an extended "Related Work" section. Such as an
extended related work section can be thought of as an annotated
bibliography: It is a list of references, with your comment about
these references. It is useful (for you, mainly) to have your
comments about all papers that you have read. More important for
presentation to me is how you classify these papers (that is, how
you organize them into related groups) and how you explain the
relation between each of these other projects and your work.
- Vitally, you need to add specific citations. Yes, it is very
useful to explain how the literature can be divided, but it is
essential that such an explanation comes with statements about how
individual papers fall in each group. It is also especially important
that you identify both examples papers in each group as well as
the papers that you and others view as important (not necessarily
the same).
Things that need rethinking:
- Whatever classification you introduce, you should make sure that
you already know where your work falls. It might be useful for
you to make a table (similar to the one in the concoqtion paper)
as you are trying to figure out how to organize the related work.
It is OK to find that you are redoing the table several times
until you get to something that you are happy with.
- Avoid complex definitions, especially for things that are not
necessarily essential for your related work section. Examples
are the subjects of operational and denotational semantics. If
you think about what you have done, you have not really focused
on related work. Instead, you tried to explain why there are
problems with operational and denotational semantics based design.
This is not a good idea, for two reasons. First, it may not
be something that can be done very clearly. Second, it is not
essential for your goal, which is organizing the related work,
and explaining where in this context your paper falls.
- When you are doing a classification of papers, you can't do that
based on the title or the topic or what you heard about papers
or projects. You really have to read the papers carefully and
determine for yourself what you think about the extent and the
way they have managed (or not managed) to solve "The Problem(s)"
that you have identified at the beginning of your related work
section.
Subscribe to:
Posts (Atom)