I have done a GUI with LispWorks. When the program is executing a complex
algorithm, I can�t push any button, for example, to stop that algorithm,
because the system is busy and doesn�t respond to any push. Is there any way
to stop the execution with a button of my GUI? Currently I do this with the
LispWorks's Process Browser, breaking the program, but i want to make an
.exe file from the lisp code and I won�t be able to use the System Browser
with the .exe.
Thankyou,
Rafa.
"Rafael Le�n" <····@albireo.lcc.uma.es> writes:
> I have done a GUI with LispWorks. When the program is executing a complex
> algorithm, I can�t push any button, for example, to stop that algorithm,
> because the system is busy and doesn�t respond to any push. Is there any way
> to stop the execution with a button of my GUI? Currently I do this with the
> LispWorks's Process Browser, breaking the program, but i want to make an
> .exe file from the lisp code and I won�t be able to use the System Browser
> with the .exe.
One approach would be to display a progress-bar during the execution
of your algorithm. The progress bar could have a 'stop' button to
allow the algorithm to be terminated before completion. If you could
show progress towards completion so much the better as your end-user
doesn't then run the risk of stopping execution just before
completion.
I'm afraid I don't know the appropriate widget in Lispworks.
Mark
* Rafael Le�n wrote:
> I have done a GUI with LispWorks. When the program is executing a complex
> algorithm, I can�t push any button, for example, to stop that algorithm,
> because the system is busy and doesn�t respond to any push. Is there any way
> to stop the execution with a button of my GUI? Currently I do this with the
> LispWorks's Process Browser, breaking the program, but i want to make an
> .exe file from the lisp code and I won�t be able to use the System Browser
> with the .exe.
You need to do this by making the complex operation run in a separate
thread, and having the thread that handles the button presses do
things to control the algorithm thread.
--tim
>>>>> "Tim" == Tim Bradshaw <···@cley.com> writes:
Tim> * Rafael Le�n wrote:
>> I have done a GUI with LispWorks. When the program is executing
>> a complex algorithm, I can�t push any button, for example, to
>> stop that
>> algorithm, because the system is busy and doesn�t respond to
>> any push. Is there any way to stop the execution with a button
>> of my GUI?
>> Currently I do this with the LispWorks's Process Browser,
>> breaking the program, but i want to make an .exe file from the
>> lisp code and I
>> won�t be able to use the System Browser with the .exe.
Tim> You need to do this by making the complex operation run in a
Tim> separate thread, and having the thread that handles the
Tim> button presses do things to control the algorithm thread.
Does this have to be done with threads? One idea mentioned recently (I
think) on c.l.python was to do it with a generator running the
CPU-heavy task, so that it can occasionally yield and allow the
program to check for other input. We can do the same thing with
closures, right?
-- Anudder Tim
* Tim Lavoie wrote:
> Does this have to be done with threads? One idea mentioned recently (I
> think) on c.l.python was to do it with a generator running the
> CPU-heavy task, so that it can occasionally yield and allow the
> program to check for other input. We can do the same thing with
> closures, right?
Well, maybe, but why would you want to do this, since you have
threads? Morris's corollary to Greenspun's 10th law applies, I think.
--tim
>>>>> "Tim" == Tim Bradshaw <···@cley.com> writes:
Tim> * Tim Lavoie wrote:
>> Does this have to be done with threads? One idea mentioned
>> recently (I think) on c.l.python was to do it with a generator
>> running the CPU-heavy task, so that it can occasionally yield
>> and allow the program to check for other input. We can do the
>> same thing with closures, right?
Tim> Well, maybe, but why would you want to do this, since you
Tim> have threads? Morris's corollary to Greenspun's 10th law
Tim> applies, I think.
Sure, and threads are more common, but still not universal. Having
another way to do something useful can't hurt, and may occasionally
fit better.
--
I argue very well. Ask any of my remaining friends. I can win an argument on
any topic, against any opponent. People know this, and steer clear of me at
parties. Often, as a sign of their great respect, they don't even invite me.
-- Dave Barry
Tim Lavoie <·······@acm.org> writes:
> >>>>> "Tim" == Tim Bradshaw <···@cley.com> writes:
>
> Tim> * Tim Lavoie wrote:
> >> Does this have to be done with threads? One idea mentioned
> >> recently (I think) on c.l.python was to do it with a generator
> >> running the CPU-heavy task, so that it can occasionally yield
> >> and allow the program to check for other input. We can do the
> >> same thing with closures, right?
>
> Tim> Well, maybe, but why would you want to do this, since you
> Tim> have threads? Morris's corollary to Greenspun's 10th law
> Tim> applies, I think.
>
> Sure, and threads are more common, but still not universal. Having
> another way to do something useful can't hurt, and may occasionally
> fit better.
In the context of a LispWorks GUI question, why would you balk at
threads because, say, CLISP doesn't support them? As something to
have in your general toolbox of programming techniques, yes it is good
to know how make a thread do more than one thing. The lower-tech way
is to write your own driver system, the nicer way is to use something
like CMUCL's event server architecture, and insert yeilds in key
places (tops of functions, tops of non-inner loops). But this is
fairly off-topic for this thread...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
* Tim Lavoie wrote:
> Sure, and threads are more common, but still not universal. Having
> another way to do something useful can't hurt, and may occasionally
> fit better.
In the context of LispWorks GUI issues they are universal.
--tim
>>>>> "Tim" == Tim Bradshaw <···@cley.com> writes:
Tim> * Tim Lavoie wrote:
>> Sure, and threads are more common, but still not
>> universal. Having another way to do something useful can't
>> hurt, and may occasionally fit better.
Tim> In the context of LispWorks GUI issues they are universal.
OK, fair enough, I guess I wandered off on a tangent...