I wanted to analyse the execution of my code using trace, and hence I entered
(trace oddp)
into the REPL. In contrast to what I expected I got an error message telling me:
** - Continuable Error
TRACE(ODDP): #<PACKAGE COMMON-LISP> is locked
If you continue (by typing 'continue'): Ignore the lock and proceed
What exactly does this mean, why does it happen, and is it safe to proceed by ignoring the lock?
TRACE works by redefining the function to something that prints the trace messages and then calls the original function. But you're not normally allowed to redefine built-in functions, so you get this error.
Related
Is there way to tell WinDbg to ignore program breakpoints like caused by DebugBreak function?
Have a look at the Controlling Exceptions and Events page on MSDN. It explains how to use the sx* commands to break, ignore, or print exceptions/events as they happen.
What you are looking for is probably:
sxn bpe
This tells the debugger to print a message without breaking when a breakpoint exception (0x80000003) occurs.
Typical debugger output looks like:
(b70.11fc): Break instruction exception - code 80000003 (first chance)
I'm minimizing a function with the fmincon routine.
This function uses the integral command several times. However, some of those integrals turns out to be Inf or NaN and I don't want MATLAB to show a warning when this happens (the function is always finite).
I've tried using the command warning('off','MATLAB:integral:NonFiniteValue') but it don't seem to be working when running the optimization.
It could be you're simply suppressing the wrong message. You could inspect the values of
[a,b] = lastwarn
inside an output function (opts = optimset('OutputFcn', #myOutFcn);) to make 100% sure you're killing the correct warning message.
But I too have encountered this annoying behavior before -- you just can't seem to suppress certain warnings in MATLAB's own functions. For those, you have to resort to ugly and fragile hacks.
You could try
warning off
...
warning on
which suppresses all warnings for all code contained in the '...' section.
You could also use an undocumented feature: temporarily promote the warning to an error:
ws = warning('error', 'MATLAB:integral:NonFiniteValue');
...
warning(ws);
and wrap it up in a try....catch. Chances are you then interrupt integral and thus fmincon prematurely and will thus have to wrap it up together with some rescue mechanism, but that gets real complicated and real ugly real fast, so that's only to be used as a last resort...
...so in all, it's easiest to just live with the warnings.
There's an alternative way: click on the uppermost link in inner matlab files that produced that warning, find warning ID & copy it into clipboard.
Then add the following line to your script:
warning('off','IDHERE');
Replace IDHERE with actual ID
See https://tushev.org/articles/blog/17/how-to-suppress-matlab-warnings
Ever since I installed emacs24 some tiny insignificant piece of my configuration files stopped working. Since I don't really care about this error and It does not affect me I just want Emacs to shut up about initialization warnings and just open the scratch buffer (as it is it opens a second buffer with some error stuff).
Is there a way to do this without having to sit hours to debug lisp code I don't understand?
I really can't post the configuration file because it's really really big and messy, but this is the warning I get:
Warning (initialization): An error occurred while loading `/home/sofia/.emacs':
Symbol's function definition is void: plist-to-alist
To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file. Start Emacs with the
`--debug-init' option to view a complete error backtrace.
In a nutshell, I don't want to ensure normal operation, I just want one buffer when opening emacs
I'm not saying that it's a good idea to do this (in fact I very much agree with #Carl Groner and #rashimoto that masking errors instead of fixing them is usually a Bad Idea™), but at your own risk try adding the following to the top of your .emacs file:
(setq warning-minimum-level :emergency)
This tells Emacs not to warn you about anything except problems
that will seriously impair Emacs operation soon if you do not attend to [them] promptly.
By contrast, the default value of warning-minimum-level is :warning, which causes Emacs to warn you about
data or circumstances that are not inherently wrong, but raise suspicion of a possible problem.
More info about warnings and options for dealing with them here and here.
You can set a breakpoint on the closing } of a Scala method, but it's pointless to do so because it won't be hit, apparently.
I would still like to set it there. So I thought, "how about I put in a no-op before that line, and set a breakpoint on that?"
But since evidently Eclipse is not warning me when I try to set a breakpoint that will never be hit (because there is no code there), I therefore can't rely on Eclipse telling me if a no-op has been optimised out (particularly as I'm not even using the same version of Scala to run the code as the Eclipse Scala plugin is using).
So is there a short no-operation statement or expression that I can use here which is guaranteed not to be optimised away by the Scala compiler, in all circumstances - and guaranteed not to be optimised away by a JIT in a way that prevents a breakpoint on it being hit? I guess it has to be an expression rather than a statement in my case, because this method returns a useful value, not Unit.
It's not exactly a no-op, but a logging statement (or trace expression - i.e. a logging statement which additionally returns the value it has just logged) is guaranteed not to be optimised away!
The only trouble with that is, you have to manually step over the debug statement or trace expression each time you hit the breakpoint, if you want to see what it actually outputs. Unless it's just outputting the value of a variable, in which case you can find that variable in the Variables tab in Eclipse.
And stepping over a trace expression, at least in my code, with the Eclipse Scala plugin 2.1 milestone 2, in "old-style debugging mode", is no small matter - because it's completely broken, due to this issue!
Before I realised what was going on, it took me about 20 tries of pounding the F6 and F7 keys before I finally managed to step over it! And that was just for stepping over it once!
And remember, the next line is the } - so the obvious workaround, setting another breakpoint on the next line - won't work!
Theoretically you should just be able to Inspect the value being traced, rather than trying to step over the trace. Unfortunately, that doesn't work for me either - it says class not found.
From time to time I get a "nesting exceeds `max-lisp-eval-depth'" error.
What does it mean?
When I get one, is there something I can do, other than "killall emacs"?
Edit:
You can get the error if you evaluate:
(defun func ()
(func))
(func)
However, in this case emacs remains responsive.
An immediate remedy can be to simply increase the maximum. Its default value is 500, but you could set it to, say, 10000 like this:
(setq max-lisp-eval-depth 10000)
But that's generally not a great idea, because the fact that you run into a nesting exceeds `max-lisp-eval-depth' error in the first place is a sign that some part of your code is taking up too much stack space. But at least increasing the maximum temporarily can help you analyze the problem without getting the same error message over and over again.
Basically, it means that some Lisp code used up more stack than Emacs was compiled to permit.
In practice, it's a sign of a bug in Lisp code. Correctly written code should avoid nesting this deeply, even if the algorithm and the input data were "correct"; but more frequently, it happens because of an unhandled corner case or unexpected input.
In other words, you have probably created an endless loop via recusion, or perhaps e.g. a regular expression with exponential backtracking.
If you are lucky, repeated control-G keypresses could get you out of the conundrum without killing Emacs.
If you are developing Emacs Lisp code, you might want to tweak down the value of max-lisp-eval-depth artificially to help find spots where your code might need hardening or bug fixing. And of course, having debug-on-error set to t should help by showing you a backtrace of the stack.