Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Sending an interrupt to the frontend?
249 views
Skip to first unread message
John Fultz
Jul 11, 2012, 2:18:32 AM7/11/12
to
It would be nice if the front end were more responsive in these cases (says the
guy who would be responsible for making it happen). In the mean time, one thing
which usually works pretty well is to kill the MathKernel process. Doing so
will typically leave your front end intact and make it responsive again.
You can do this pretty easily from the Activity Monitor in MacOS, or the Task
Manager (looking at the Processes tab...*not* the Applications tab) in Windows.
Sincerely,
John Fultz
jfu...@wolfram.com
User Interface Group
Wolfram Research, Inc.
On Tue, 10 Jul 2012 00:40:50 -0400 (EDT), W Craig Carter wrote:
>
> Hello Mathgroup,
>
> This is a question about frozen frontend behavior.
>
> In development stages, one of my frequent mistakes is to send the
> frontend something that takes forever to dynamically update---at least
> that is what I believe what is happening for most of the "freezing"
> occurrences. For MacOs, this is often signaled by a "Formatting
> Notebook Contents" window.
>
> I wonder if anyone has found a method to send the front end a message to
> stop dynamically updating while in an unresponsive state? I've various
> versions of kill -s signal (i.e., signal = INT) from a terminal in
> MacOSx, but never with success.
>
> I suppose that having the front end query the operating system for
> interrupt requests would create a lot of overhead. However, I wonder if
> a method to force the frontend to make an operating system query with a
> user-specified time interval might be possible?
>
> W Craig Carter
guy who would be responsible for making it happen). In the mean time, one thing
which usually works pretty well is to kill the MathKernel process. Doing so
will typically leave your front end intact and make it responsive again.
You can do this pretty easily from the Activity Monitor in MacOS, or the Task
Manager (looking at the Processes tab...*not* the Applications tab) in Windows.
Sincerely,
John Fultz
jfu...@wolfram.com
User Interface Group
Wolfram Research, Inc.
On Tue, 10 Jul 2012 00:40:50 -0400 (EDT), W Craig Carter wrote:
>
> Hello Mathgroup,
>
> This is a question about frozen frontend behavior.
>
> In development stages, one of my frequent mistakes is to send the
> frontend something that takes forever to dynamically update---at least
> that is what I believe what is happening for most of the "freezing"
> occurrences. For MacOs, this is often signaled by a "Formatting
> Notebook Contents" window.
>
> I wonder if anyone has found a method to send the front end a message to
> stop dynamically updating while in an unresponsive state? I've various
> versions of kill -s signal (i.e., signal = INT) from a terminal in
> MacOSx, but never with success.
>
> I suppose that having the front end query the operating system for
> interrupt requests would create a lot of overhead. However, I wonder if
> a method to force the frontend to make an operating system query with a
> user-specified time interval might be possible?
>
> W Craig Carter
Yves Klett
Jul 12, 2012, 5:00:32 AM7/12/12
to
In earlier incarnations, the kernel would show up as a separate entry in
the taskbar (on Win XP, that was), which made it very convenient to
kill. I kind of miss that behaviour (when things go wrong repeatedly).
Regards,
Yves
the taskbar (on Win XP, that was), which made it very convenient to
kill. I kind of miss that behaviour (when things go wrong repeatedly).
Regards,
Yves
David Bailey
Jul 14, 2012, 1:30:08 AM7/14/12
to
On 12/07/2012 10:00, Yves Klett wrote:
> In earlier incarnations, the kernel would show up as a separate entry in
> the taskbar (on Win XP, that was), which made it very convenient to
> kill. I kind of miss that behaviour (when things go wrong repeatedly).
I wrote a C program that executes the command
> In earlier incarnations, the kernel would show up as a separate entry in
> the taskbar (on Win XP, that was), which made it very convenient to
> kill. I kind of miss that behaviour (when things go wrong repeatedly).
c:\windows\System32\taskkill.exe /im MathKernel.exe /t /f
This runs in the background all the time, and responds to a hot key!
The fact that I took time to set this up, probably reflects just how
troublesome kernel hangs can be!
Perhaps at the very least Mathematica could spawn a program of this type.
David Bailey
http://www.dbaileyconsultancy.co.uk
Ralph Dratman
Jul 15, 2012, 4:28:24 AM7/15/12
to
David,
"Troublesome" puts the matter rather tactfully.
Bluntly, there is no excuse for a major product to display such a
level of instability in 2012.
Since I personally like Mathematica so much, and because I use it
constantly, I find the crashes to be both an embarrassment and a
disappointment.
I can only hope Wolfram Research will soon get its act together on
this critically important issue.
Ralph
"Troublesome" puts the matter rather tactfully.
Bluntly, there is no excuse for a major product to display such a
level of instability in 2012.
Since I personally like Mathematica so much, and because I use it
constantly, I find the crashes to be both an embarrassment and a
disappointment.
I can only hope Wolfram Research will soon get its act together on
this critically important issue.
Ralph
Alexey Popkov
Jul 15, 2012, 4:29:25 AM7/15/12
to
The default MathKernel process with name "Local" is launched (starting from
the version 6) with the '-noicon' command-line option which hides it from
the taskbar under Windows. It is possible to create auto-launching kernel
without this option (say "Local+") by using the "Kernel Configuration
dialog" and removing the '-noicon' part in the "Arguments to MLOpen" field
under "Advanced options" (one should also set "Automatically launch on fromt
end startup"). After this we can set "Local+" as the default kernel globally
in the "Evaluation :: Default kernel" menu and the kernel will show up as a
separate entry in the taskbar by default.
HTH,
Alexey
"Yves Klett" <yves....@googlemail.com> wrote:
news:jtm3ng$ge9$1...@smc.vnet.net...
the version 6) with the '-noicon' command-line option which hides it from
the taskbar under Windows. It is possible to create auto-launching kernel
without this option (say "Local+") by using the "Kernel Configuration
dialog" and removing the '-noicon' part in the "Arguments to MLOpen" field
under "Advanced options" (one should also set "Automatically launch on fromt
end startup"). After this we can set "Local+" as the default kernel globally
in the "Evaluation :: Default kernel" menu and the kernel will show up as a
separate entry in the taskbar by default.
HTH,
Alexey
"Yves Klett" <yves....@googlemail.com> wrote:
news:jtm3ng$ge9$1...@smc.vnet.net...
David Bailey
Jul 18, 2012, 1:38:56 AM7/18/12
to
On 15/07/2012 09:28, Ralph Dratman wrote:
> David,
>
> "Troublesome" puts the matter rather tactfully.
>
> Bluntly, there is no excuse for a major product to display such a
> level of instability in 2012.
>
> Since I personally like Mathematica so much, and because I use it
> constantly, I find the crashes to be both an embarrassment and a
> disappointment.
>
> I can only hope Wolfram Research will soon get its act together on
> this critically important issue.
>
> Ralph
>
I broadly agree with that - and without my solution, I would find these
> David,
>
> "Troublesome" puts the matter rather tactfully.
>
> Bluntly, there is no excuse for a major product to display such a
> level of instability in 2012.
>
> Since I personally like Mathematica so much, and because I use it
> constantly, I find the crashes to be both an embarrassment and a
> disappointment.
>
> I can only hope Wolfram Research will soon get its act together on
> this critically important issue.
>
> Ralph
>
hangs VERY frustrating!
I think I can understand if hangs happen while user code is executing,
but on occasions, this can happen for no obvious reasons - Mathematica
is just starting up!
I think it would be great if we could get a discussion of this at the
forthcoming technology conference.
David Bailey
http://www.dbaileyconsultancy.co.uk
leigh pascoe
Jul 19, 2012, 3:52:38 AM7/19/12
to
Le 18/07/2012 07:37, David Bailey a =C3=A9crit :
reason and the only solution is to kill the process and restart, often
losing work in progress. I posted a query about this several times on
the forum, but got no replies apart from someone who confirmed that they
experienced the same problem. It is difficult to contact Wolfram
technical help without a specific sequence that crashes the program.
Leigh
> On 15/07/2012 09:28, Ralph Dratman wrote:
>> David,
>>
>> "Troublesome" puts the matter rather tactfully.
>>
>> Bluntly, there is no excuse for a major product to display such a
>> level of instability in 2012.
>>
>> Since I personally like Mathematica so much, and because I use it
>> constantly, I find the crashes to be both an embarrassment and a
>> disappointment.
>>
>> I can only hope Wolfram Research will soon get its act together on
>> this critically important issue.
>>
>> Ralph
>>
>>
>> "Troublesome" puts the matter rather tactfully.
>>
>> Bluntly, there is no excuse for a major product to display such a
>> level of instability in 2012.
>>
>> Since I personally like Mathematica so much, and because I use it
>> constantly, I find the crashes to be both an embarrassment and a
>> disappointment.
>>
>> I can only hope Wolfram Research will soon get its act together on
>> this critically important issue.
>>
>> Ralph
>>
> I broadly agree with that - and without my solution, I would find these
> hangs VERY frustrating!
>
> I think I can understand if hangs happen while user code is executing,
> but on occasions, this can happen for no obvious reasons - Mathematica
> is just starting up!
>
> I think it would be great if we could get a discussion of this at the
> forthcoming technology conference.
>
> David Bailey
> http://www.dbaileyconsultancy.co.uk
>
>
>
I would also agree with that. Mathematica seems to hang for no apparent
> hangs VERY frustrating!
>
> I think I can understand if hangs happen while user code is executing,
> but on occasions, this can happen for no obvious reasons - Mathematica
> is just starting up!
>
> I think it would be great if we could get a discussion of this at the
> forthcoming technology conference.
>
> David Bailey
> http://www.dbaileyconsultancy.co.uk
>
>
>
reason and the only solution is to kill the process and restart, often
losing work in progress. I posted a query about this several times on
the forum, but got no replies apart from someone who confirmed that they
experienced the same problem. It is difficult to contact Wolfram
technical help without a specific sequence that crashes the program.
Leigh
Michael Weyrauch
Jul 19, 2012, 3:51:37 AM7/19/12
to
Ralph,
I really would like to understand your critical remarks somewhat
better.
It is clear that one can easily and quickly run the frontend irresponsive.
However, in most cases I know, this is actually due to bad programming
(from Mathematica's point of view) rather than an instable product.
One typical reason is that a command returns symbolic results where the
programmer actually expected only numerical stuff, and quickly things get completely out of hand. But how should Mathematica know that all this was not intended?
It is the tremendous flexibility and the many possibilities which
sometims get into the way, and as a consequence the frontend can not
handle the output from the kernel any more.
I really do not understand where you expect Wolfram to get "its act
together". My experience tells me: A good Mathematica program may run
for days without any instability. But my stupitidy and/or lasy
programming can run it against
the wall within seconds. Mathematica as such is definitely not unstable.
(of course, sometimes there are bugs as with any other major (and minor)
software).
Michael
I really would like to understand your critical remarks somewhat
better.
It is clear that one can easily and quickly run the frontend irresponsive.
However, in most cases I know, this is actually due to bad programming
(from Mathematica's point of view) rather than an instable product.
One typical reason is that a command returns symbolic results where the
programmer actually expected only numerical stuff, and quickly things get completely out of hand. But how should Mathematica know that all this was not intended?
It is the tremendous flexibility and the many possibilities which
sometims get into the way, and as a consequence the frontend can not
handle the output from the kernel any more.
I really do not understand where you expect Wolfram to get "its act
together". My experience tells me: A good Mathematica program may run
for days without any instability. But my stupitidy and/or lasy
programming can run it against
the wall within seconds. Mathematica as such is definitely not unstable.
(of course, sometimes there are bugs as with any other major (and minor)
software).
Michael
W Craig Carter
Jul 20, 2012, 3:50:40 AM7/20/12
to
Yikes.
As the original poster, I'd like to clarify that I was looking for a
way to send an interrupt to the front-end *from the operating system*.
I think mathematica's behavior is understandable when the front end
receives a request to dynamically update a result that is so large that
takes a long time to format. This is nearly always triggered by a
mistake that I have made.
I was looking for a work-around; not a fix to Mathematica. Ralph
Draftman send a nice way to catch interrupts with an
Internal`AddHandler.
W Craig Carter
Professor of Materials Science, MIT
As the original poster, I'd like to clarify that I was looking for a
way to send an interrupt to the front-end *from the operating system*.
I think mathematica's behavior is understandable when the front end
receives a request to dynamically update a result that is so large that
takes a long time to format. This is nearly always triggered by a
mistake that I have made.
I was looking for a work-around; not a fix to Mathematica. Ralph
Draftman send a nice way to catch interrupts with an
Internal`AddHandler.
W Craig Carter
Professor of Materials Science, MIT
James Stein
Jul 20, 2012, 3:52:11 AM7/20/12
to
Dear Michael,
You asked of Ralph; but I wish to answer as well (although my opinions
of Mathematica are much higher than Ralph's).
Most users sometimes make mistakes. (I make many.) Sometimes an
evaluation which ought to complete in a short time takes a long time
and may be on its way to infinity. Finite beings will wish to abort
such evaluations.
Were Mathematica a single process, occasional difficulty in
interrupting a calculation would be understandable, perhaps
forgivable, perhaps unpreventable. Whatever tight (efficient) loops
may exist in the program could be substantially slowed if they had to
"listen for interrupts"; possible solutions are difficult because
different hardwares and different operating systems differ
substantially.
But as I understand it, Mathematica is commonly implemented as two
processes, a FrontEnd (the interactive Notebook) and a BackEnd (the
kernel). Assume the kernel is running away, computing an Ackermann
function perhaps. I imagine two cases: (1) the kernel is busy
computing and sending no output. (2) the kernel is flooding the
FrontEnd with more output than it can format and handle in real time.
Case 1 seems unproblematic to me. The FrontEnd is idle, it should be
easy to respond to human input and interrupt the kernel if possible,
otherwise abort it. In either case, the FrontEnd should survive and
Notebooks can be saved.
Case 2 is the problem. Both the FrontEnd and the BackEnd are busy busy
busy. If the FrontEnd is merely receiving a gazillion short lines to
output, it seems it could handle interrupts after every line. So
likely the problem is when the FrontEnd receives an output so large in
size that it goes into a very long loop formatting that output. I
would hope that somewhere in that loop would be a place to look for
interrupts. This would slow formatting (not by much, I would hope),
but in normal cases this would not matter much (10.1 seconds instead
of 10 seconds) and in the problematic case, does user care if
formatting takes 12 years and a month instead of 12 years?
So that's my naive view, and why I think the problem ought be
solvable, unless in the face of memory issues. In olden times, when
the stack crashed into the heap, all bets were off. I'm not aware of
how more modern memory management works, but would hope that the
FrontEnd, while checking for an interrupt could also check for how
much free memory remains and, if it looks dubious, could do something
intelligent (alert user and wait?) before disaster strikes.
Of course, I am a computer dinosaur so these views may look very silly
to current experts.
Best regards to all, -- James
On Thu, Jul 19, 2012 at 12:50 AM, Michael Weyrauch
<michael....@gmx.de> wrote:
> Ralph,
>
> I really would like to understand your critical remarks somewhat
> better.
>
You asked of Ralph; but I wish to answer as well (although my opinions
of Mathematica are much higher than Ralph's).
Most users sometimes make mistakes. (I make many.) Sometimes an
evaluation which ought to complete in a short time takes a long time
and may be on its way to infinity. Finite beings will wish to abort
such evaluations.
Were Mathematica a single process, occasional difficulty in
interrupting a calculation would be understandable, perhaps
forgivable, perhaps unpreventable. Whatever tight (efficient) loops
may exist in the program could be substantially slowed if they had to
"listen for interrupts"; possible solutions are difficult because
different hardwares and different operating systems differ
substantially.
But as I understand it, Mathematica is commonly implemented as two
processes, a FrontEnd (the interactive Notebook) and a BackEnd (the
kernel). Assume the kernel is running away, computing an Ackermann
function perhaps. I imagine two cases: (1) the kernel is busy
computing and sending no output. (2) the kernel is flooding the
FrontEnd with more output than it can format and handle in real time.
Case 1 seems unproblematic to me. The FrontEnd is idle, it should be
easy to respond to human input and interrupt the kernel if possible,
otherwise abort it. In either case, the FrontEnd should survive and
Notebooks can be saved.
Case 2 is the problem. Both the FrontEnd and the BackEnd are busy busy
busy. If the FrontEnd is merely receiving a gazillion short lines to
output, it seems it could handle interrupts after every line. So
likely the problem is when the FrontEnd receives an output so large in
size that it goes into a very long loop formatting that output. I
would hope that somewhere in that loop would be a place to look for
interrupts. This would slow formatting (not by much, I would hope),
but in normal cases this would not matter much (10.1 seconds instead
of 10 seconds) and in the problematic case, does user care if
formatting takes 12 years and a month instead of 12 years?
So that's my naive view, and why I think the problem ought be
solvable, unless in the face of memory issues. In olden times, when
the stack crashed into the heap, all bets were off. I'm not aware of
how more modern memory management works, but would hope that the
FrontEnd, while checking for an interrupt could also check for how
much free memory remains and, if it looks dubious, could do something
intelligent (alert user and wait?) before disaster strikes.
Of course, I am a computer dinosaur so these views may look very silly
to current experts.
Best regards to all, -- James
On Thu, Jul 19, 2012 at 12:50 AM, Michael Weyrauch
<michael....@gmx.de> wrote:
> Ralph,
>
> I really would like to understand your critical remarks somewhat
> better.
>
> It is clear that one can easily and quickly run the frontend irresponsive.
> However, in most cases I know, this is actually due to bad programming
> (from Mathematica's point of view) rather than an instable product.
>
> One typical reason is that a command returns symbolic results where the
> programmer actually expected only numerical stuff, and quickly things get completely out of hand. But how should Mathematica know that all this was not intended?
>
> However, in most cases I know, this is actually due to bad programming
> (from Mathematica's point of view) rather than an instable product.
>
> One typical reason is that a command returns symbolic results where the
> programmer actually expected only numerical stuff, and quickly things get completely out of hand. But how should Mathematica know that all this was not intended?
>
> It is the tremendous flexibility and the many possibilities which
> sometims get into the way, and as a consequence the frontend can not
> handle the output from the kernel any more.
>
> I really do not understand where you expect Wolfram to get "its act
> together". My experience tells me: A good Mathematica program may run
> for days without any instability. But my stupitidy and/or lasy
> programming can run it against
> the wall within seconds. Mathematica as such is definitely not unstable.
> (of course, sometimes there are bugs as with any other major (and minor)
> software).
>
> Michael
>
>
> Am 15.07.2012 10:28, schrieb Ralph Dratman:
> sometims get into the way, and as a consequence the frontend can not
> handle the output from the kernel any more.
>
> I really do not understand where you expect Wolfram to get "its act
> together". My experience tells me: A good Mathematica program may run
> for days without any instability. But my stupitidy and/or lasy
> programming can run it against
> the wall within seconds. Mathematica as such is definitely not unstable.
> (of course, sometimes there are bugs as with any other major (and minor)
> software).
>
> Michael
>
>
> Am 15.07.2012 10:28, schrieb Ralph Dratman:
Bill Rowe
Jul 20, 2012, 3:55:12 AM7/20/12
to
On 7/19/12 at 3:51 AM, le...@evry.inserm.fr (leigh pascoe) wrote:
>I would also agree with that. Mathematica seems to hang for no
>apparent reason
There is always a reason. But determining the true reason for a
>I would also agree with that. Mathematica seems to hang for no
>apparent reason
crash is often very time consuming and far from easy.
>and the only solution is to kill the process and restart, often losing
>work in progress.
usual consequence of killing a program.
>I posted a query about this several times on the forum, but got no
>replies apart from someone who confirmed that they experienced the same
>problem. It is difficult to contact Wolfram technical help without a
>specific sequence that crashes the program.
much anyone can do. Even if I seem to get a similar crash
running code that seems to match your description, there can be
no assurance whatever the root cause is the same. And if I
cannot duplicate the crash, clearly there is nothing I can do to
resolve the fundamental issue.
Note, I personally don't work for Wolfram and have no access to
the source code for Mathematica. But this really changes
nothing. For anything that is not working correctly be it
Mathematica, another program, you car whatever, the first
essential step is to be able to duplicate the undesired behavior.
Also, even if Mathematica were totally bug free (as in
everything works precisely as documented, not necessarily as you
might expect), Mathematic would still not be crash free.
Mathematica give you a tool set that allows you to do
arbitrarily complex problems. Any tool set that gives you this
much power will give you the power to write code that crashes
your system whether or not that is your intent. Additionally, it
is simply not feasible for Mathematica to check code of
arbitrary complexity for problems that lead to crashes.
Algorithms for checking sufficiently complex code probably don't
exist or don't execute in reasonable time.
I am not suggesting Wolfram should not do everything they can to
make Mathematic robust and fail in graceful ways rather than
simply crash. I am saying there are very real limits to what
Wolfram can achieve in this regard.
I've been using Mathematica on an almost daily basis for the
past 10-20 years. And yes, I too manage to crash Mathematica now
and then (for some reason far more often under Windows than
under Mac OS X). And yes, I've lost work and am often quite
annoyed when this happens.
But, invariably, the root cause turns out not to be a bug in
Mathematica. Rather it is something I did that doesn't make
sense. Often this means, syntax errors or typos on my part that
get interpreted as valid Mathematica code but far from what I
intended. Or setting up a problem that needs far more memory
than I expected or have installed in my system. Or a myriad of
other things along these lines.
David Bailey
Jul 22, 2012, 4:32:19 AM7/22/12
to
On 19/07/2012 08:51, Michael Weyrauch wrote:
> Ralph,
>
> I really would like to understand your critical remarks somewhat
> better.
>
> It is clear that one can easily and quickly run the frontend irresponsive.
> However, in most cases I know, this is actually due to bad programming
> (from Mathematica's point of view) rather than an instable product.
>
> One typical reason is that a command returns symbolic results where the
> programmer actually expected only numerical stuff, and quickly things get completely out of hand. But how should Mathematica know that all this was not intended?
>
> It is the tremendous flexibility and the many possibilities which
> sometims get into the way, and as a consequence the frontend can not
> handle the output from the kernel any more.
>
> I really do not understand where you expect Wolfram to get "its act
> together". My experience tells me: A good Mathematica program may run
> for days without any instability. But my stupitidy and/or lasy
> programming can run it against
> the wall within seconds. Mathematica as such is definitely not unstable.
> (of course, sometimes there are bugs as with any other major (and minor)
> software).
>
> Michael
>
I am not sure it is always as simple as just blaming the user! I have
> Ralph,
>
> I really would like to understand your critical remarks somewhat
> better.
>
> It is clear that one can easily and quickly run the frontend irresponsive.
> However, in most cases I know, this is actually due to bad programming
> (from Mathematica's point of view) rather than an instable product.
>
> One typical reason is that a command returns symbolic results where the
> programmer actually expected only numerical stuff, and quickly things get completely out of hand. But how should Mathematica know that all this was not intended?
>
> It is the tremendous flexibility and the many possibilities which
> sometims get into the way, and as a consequence the frontend can not
> handle the output from the kernel any more.
>
> I really do not understand where you expect Wolfram to get "its act
> together". My experience tells me: A good Mathematica program may run
> for days without any instability. But my stupitidy and/or lasy
> programming can run it against
> the wall within seconds. Mathematica as such is definitely not unstable.
> (of course, sometimes there are bugs as with any other major (and minor)
> software).
>
> Michael
>
seen Mathematica hang when all I have done is start it up and look
something up in the help system (or try to).
My feeling is that Mathematica could learn something from the Windows
GUI. When most events happen in Windows (e.g. someone pushes a button),
the information doesn't get posted into the program pre-emptively, as I
think happens with Mathematica - it gets added to a list of messages,
which is read in a message loop. This means that everything happens in a
predictable way, without race hazards. I strongly suspect that this is
why Mathematica has a slightly glitchy feel. I really don't understand
why WRI feel this problem is insoluble (assuming they do - it has been
like that since version 6.0).
That leaves complicated situations involving Dynamic. This may indeed
create tricky problems, but if so, why didn't WRI use a more robust scheme?
David Bailey
http://www.dbaileyconsultancy.co.uk
James Stein
Jul 23, 2012, 1:03:18 AM7/23/12
to
On Sun, Jul 22, 2012 at 1:31 AM, David Bailey <da...@removedbailey.co.uk>wrote:
>
> I am not sure it is always as simple as just blaming the user! I have
> seen Mathematica hang when all I have done is start it up and look
> something up in the help system (or try to).
>
I also have seen the bad behavior Dave reports, in two guises:
>
> I am not sure it is always as simple as just blaming the user! I have
> seen Mathematica hang when all I have done is start it up and look
> something up in the help system (or try to).
>
(a) launch mathematica, and it hangs (before, I think, showing the splash screen).
(b) launch Mathematica, access help system, and it hangs while "formatting".
(On a Macintosh, fwiw)
Ralph Dratman
Jul 23, 2012, 1:05:52 AM7/23/12
to
Michael,
I understand your point about "bad programming," but must respectfully
disagree. I am only asking that the front end remain responsive to a
user interrupt, no matter what else happens. It already has a very
nice menu item to stop evaluation. Why should such a command ever
fail, or be shown as disabled?
This is not magic, but ordinary system-level programming. It may
amount to just a few hundred lines of code, causing no loss of
performance whatsoever. There are probably a dozen technical people at
Wolfram who are perfectly capable of fixing the problem.
Anyway, perhaps I am not being quite as harsh or negative as you
think. A bit of direct talk is necessary in this case. I would not be
writing anything at all if I did not like Mathematica as much as I do.
Ralph
I understand your point about "bad programming," but must respectfully
disagree. I am only asking that the front end remain responsive to a
user interrupt, no matter what else happens. It already has a very
nice menu item to stop evaluation. Why should such a command ever
fail, or be shown as disabled?
This is not magic, but ordinary system-level programming. It may
amount to just a few hundred lines of code, causing no loss of
performance whatsoever. There are probably a dozen technical people at
Wolfram who are perfectly capable of fixing the problem.
Anyway, perhaps I am not being quite as harsh or negative as you
think. A bit of direct talk is necessary in this case. I would not be
writing anything at all if I did not like Mathematica as much as I do.
Ralph
Ralph Dratman
Jul 23, 2012, 7:55:13 PM7/23/12
to
James,
In your case I suggest you try reinstalling Mathematica. That might
help with the kinds of crashes you describe, which should never
happen.
Ralph
In your case I suggest you try reinstalling Mathematica. That might
help with the kinds of crashes you describe, which should never
happen.
Ralph
George Woodrow III
Jul 23, 2012, 7:56:14 PM7/23/12
to
I only rarely see this behaviour. (I also use Macs.)
When something like this happens, starting the app with the option key down (I think) resets Mathematica. The problems go away.
Of course, there are any number of other problems that are not helped, but this trick works for me in many cases. I might have to do this once every 6 months or a year. I had to do this most recently -- for almost exactly the symptoms you describe. The problem has not happened again.
Hope this helps.
george
When something like this happens, starting the app with the option key down (I think) resets Mathematica. The problems go away.
Of course, there are any number of other problems that are not helped, but this trick works for me in many cases. I might have to do this once every 6 months or a year. I had to do this most recently -- for almost exactly the symptoms you describe. The problem has not happened again.
Hope this helps.
george
Michael Weyrauch
Jul 23, 2012, 7:55:44 PM7/23/12
to
Ralph,
if you just ask for responsiveness to a user interrupt, then I am
fully with you. It bites me often that a calculation goes astray
because I did not anticipate correctly what is going to happen. And no
doubt, these are standard user errors which can not be avoided, and
always happen... to everyone. However, I would not call such behaviour
an instability.
I once heard on a user conference John Fultz of WRI remark about this
issue. WRI knows about that, and certainly would like to do something
about that, I understand. However, from his remarks I also understood
that this is not as easy as one might expect. I am not a system's
programmer, and therefore not able to judge on that.
Michael
if you just ask for responsiveness to a user interrupt, then I am
fully with you. It bites me often that a calculation goes astray
because I did not anticipate correctly what is going to happen. And no
doubt, these are standard user errors which can not be avoided, and
always happen... to everyone. However, I would not call such behaviour
an instability.
I once heard on a user conference John Fultz of WRI remark about this
issue. WRI knows about that, and certainly would like to do something
about that, I understand. However, from his remarks I also understood
that this is not as easy as one might expect. I am not a system's
programmer, and therefore not able to judge on that.
Michael
Ralph Dratman
Jul 25, 2012, 2:32:08 AM7/25/12
to
Yves,
Do you know any way to prevent the insertion of code classified as
"dynamic"? I don't knowingly use any code of that kind, yet I
frequently see a message to the effect that my notebook contains
"unsafe" dynamic content!
Ralph
On Fri, Jul 20, 2012 at 3:48 AM, Yves Klett <yves....@googlemail.com> wrote:
> Michael,
>
> the subjective stability changed brutally between versions 5 and 6 with
> the introduction of the whole dynamic frontend stuff. With version 6 and
> all the very desirable interactivity the number of kernel kills rocketed
> for me.
>
> If you use this heavily there are often hangs/crashes that seem
> difficult to reproduce. Sometimes it works, sometimes it does not. Which
> can be quite vexing. Of course this may still be due to bad programming,
> but in a rather non-deterministic fashion.
>
> Regards,
> Yves
Do you know any way to prevent the insertion of code classified as
"dynamic"? I don't knowingly use any code of that kind, yet I
frequently see a message to the effect that my notebook contains
"unsafe" dynamic content!
Ralph
On Fri, Jul 20, 2012 at 3:48 AM, Yves Klett <yves....@googlemail.com> wrote:
> Michael,
>
> the subjective stability changed brutally between versions 5 and 6 with
> the introduction of the whole dynamic frontend stuff. With version 6 and
> all the very desirable interactivity the number of kernel kills rocketed
> for me.
>
> If you use this heavily there are often hangs/crashes that seem
> difficult to reproduce. Sometimes it works, sometimes it does not. Which
> can be quite vexing. Of course this may still be due to bad programming,
> but in a rather non-deterministic fashion.
>
> Regards,
> Yves
>
> Am 19.07.2012 09:51, schrieb Michael Weyrauch:
>> Ralph,
>>
>> I really would like to understand your critical remarks somewhat
>> better.
>>
>> It is clear that one can easily and quickly run the frontend irresponsive.
>> However, in most cases I know, this is actually due to bad programming
>> (from Mathematica's point of view) rather than an instable product.
>>
>> One typical reason is that a command returns symbolic results where the
>> programmer actually expected only numerical stuff, and quickly things get completely out of hand. But how should Mathematica know that all this was not intended?
>>
>> It is the tremendous flexibility and the many possibilities which
>> sometims get into the way, and as a consequence the frontend can not
>> handle the output from the kernel any more.
>>
>> I really do not understand where you expect Wolfram to get "its act
>> together". My experience tells me: A good Mathematica program may run
>> for days without any instability. But my stupitidy and/or lasy
>> programming can run it against
>> the wall within seconds. Mathematica as such is definitely not unstable.
>> (of course, sometimes there are bugs as with any other major (and minor)
>> software).
>>
>> Michael
>>
>>
> Am 19.07.2012 09:51, schrieb Michael Weyrauch:
>> Ralph,
>>
>> I really would like to understand your critical remarks somewhat
>> better.
>>
>> It is clear that one can easily and quickly run the frontend irresponsive.
>> However, in most cases I know, this is actually due to bad programming
>> (from Mathematica's point of view) rather than an instable product.
>>
>> One typical reason is that a command returns symbolic results where the
>> programmer actually expected only numerical stuff, and quickly things get completely out of hand. But how should Mathematica know that all this was not intended?
>>
>> It is the tremendous flexibility and the many possibilities which
>> sometims get into the way, and as a consequence the frontend can not
>> handle the output from the kernel any more.
>>
>> I really do not understand where you expect Wolfram to get "its act
>> together". My experience tells me: A good Mathematica program may run
>> for days without any instability. But my stupitidy and/or lasy
>> programming can run it against
>> the wall within seconds. Mathematica as such is definitely not unstable.
>> (of course, sometimes there are bugs as with any other major (and minor)
>> software).
>>
>> Michael
>>
>>
Yves Klett
Jul 26, 2012, 3:32:03 AM7/26/12
to
Ralf,
good question - some of the frontend stuff (e.g. rendered graphs) are
dynamic objects by default. Perhaps you can make up a minimal notebook
and see when that happens. The gamut of "dynamic content" may also be
wider than literally dynamic code...
Perhaps someone in the know can chime in here?
In a vague kind of way this thread may be related:
http://mathematica.stackexchange.com/questions/8357/security-of-mathematica-demonstrations
Regards,
Yves
good question - some of the frontend stuff (e.g. rendered graphs) are
dynamic objects by default. Perhaps you can make up a minimal notebook
and see when that happens. The gamut of "dynamic content" may also be
wider than literally dynamic code...
Perhaps someone in the know can chime in here?
In a vague kind of way this thread may be related:
http://mathematica.stackexchange.com/questions/8357/security-of-mathematica-demonstrations
Regards,
Yves
0 new messages