In MATLAB there is the function clear to delete all current variables. This is very useful if you start something totally new and don't want to get conflicts with earlier calculations. I'm searching something similar for Mathematica now, but I couldn't find anything except of Clear[VAR] which removes only the variable VAR.
You can use ClearAll to clear the variables and their attributes in your Global context (default) like so:
ClearAll["Global`*"]
If you're working inside a different context (e.g., notebook specific context or cell group specific context), you can do
ClearAll[Evaluate[Context[] <> "*"]]
If you want to remove all symbols from the kernel so that Mathematica doesn't recognize them anymore, you can use Remove[] similar to the above two examples.
Barring these, you can always quit the kernel with Quit[] which will remove all symbols. A fresh kernel will be initiated the next time you evaluate something.
I recommend one of two methods:
1. Keyboard shortcut to Quit[] the kernel
There is a system file KeyEventTranslations.tr that you can edit to customize keyboard shortcuts. I, as others, have added Ctrl+Q to Quit[] the kernel, allowing for a rapid clearing of all sessions variables. For more information on setting this up, see:
Customizing Mathematica shortcuts
2. Give the new Notebook a unique context
In Mathematica, the current $Context defines what Context unqualified symbol names belong to. By giving a new Notebook a unique Context, which is easily done through the Evaluation menu, the symbols used in that Notebook will not collide with unqualified symbols in other Notebooks. See the following question for more detailed information:
Mathematica - Separating Notebooks
I just realized that you might not know that unlike MATLAB, Mathematica is designed to run as two separate processes: the Front End is the user interface, and lets you work with notebooks. The Kernel does the computations. You can quit the kernel without affecting the front end, or even start more than one kernel for different notebooks, or start a kernel on a remote computer and use it with a local front end.
I believe that the only reliable way to clean everything is to Quit the kernel and re-start it (which is automatic). There are just too many things that can get modified apart from user variables/functions (including In/Out, loaded packages, system caches, etc.). So if you need a truly fresh start, I recommend Quit.
For a "soft" reset, #yoda already mentioned ClearAll["Global`*"]. There's the << Utilities`CleanSlate` package, which automates a little bit more than this. You can read the package docs inside the AddOns\ExtraPackages\Utilities\CleanSlate.m file.
In short, CleanSlate[] will attempt to take you back to the kernel state when the package was loaded. ClearInOut[] will clear In and Out to save memory.
I haven't used this package in years (except for the ClearInOut[] functionality), as the Mathematica kernel starts up quickly on modern computers, so I just use Quit. So I can't tell you how well it works.
Related
Is there a straigtforward way with ready-at-hand tooling to suspend a traced process' execution when a certain syscalls are called with specific parameters? Specifically I want to suspend program execution whenever
stat("/${SOME_PATH}")
or
readlink("/${SOME_PATH}")
are called. I aim to then attach a debugger, so that I can identify which of the hundreds of shared objects that are linked into the process is trying to access that specific path.
strace shows me the syscalls alright, and gdb does the rest. The question is, how to bring them together. This surely can be solved with custom glue-scripting, but I'd rather use a clean solution.
The problem at hand is a 3rd party toolsuite which is available only in binary form and which distribution package completely violates the LSB/FHS and good manners and places shared objects all over the filesystem, some of which are loaded from unconfigurable paths. I'd like to identify which modules of the toolsuite try to do this and either patch the binaries or to file an issue with the vendor.
This is the approach that I use for similar condition in windows debugging. Even though I think it should be possible for you too, I have not tried it with gdb in linux.
When you attached your process, set breakpoint on your system call which is for example stat in your case.
Add a condition based on esp to your breakpoint. For example you want to check stat("/$te"). value at [esp+4] should point to address of string which in this case is "/$te". Then add a condition like: *(uint32_t*)[esp+4] == "/$te". It seems that you can use strcmp() in your condition too as described here.
I think something similar to this should work for you too.
In Matlab 2014b, when I use CLEAR ALL at the beginning of the script I get the following warning,
For improved performance, consider not using CLEAR ALL within a script
which is not given in the previous releases (As I recall).
The only reason I found is that, when you call a script from outside or from other scripts you do not want to clear the variables in the workspace, and re-generate them every time again and again.
Is there any other reason that I am missing?
How does removing CLEAR ALL improves the performance when using a single script?
In R2015b, the semantics of clear were changed. Perhaps in response to the concerns raised in this question, the changes stated in the release notes are:
The clear function no longer clears debugging breakpoints. To clear breakpoints, use dbclear all.
The clear function only clears functions that are not currently running. For example, when you call clear myFun while myFun is running, myFun is not cleared.
This part pertains to pre-R2015b MATLAB versions.
Here's a table of what gets cleared with each input argument.
The table for R2015b is identical except that there is no longer a "Debugging breakpoints" column since they are no longer cleared with clear.
Scripts and functions are cleared, when you can probably just clear variables (red boxes). It does not make a lot of sense to clear the function from memory that is presently being executed. (According to R2015b release notes, this does not happen.)
Also, keeping in mind that scripts execute in the base workspace, you are clearing out all functions that may be used by other scripts. Try looking at the output of inmem after an extended MATLAB tinkering session. You fill find all kinds of MATLAB functions that are loaded into memory for fast access (including 'matlabrc', 'pathdef', and other core scripts that setup your workspace). So, perhaps it's not that it hurts performance of just the script where you call clear all but all other scripts and the interactive command line that is in the base workspace. That would be my guess.
Not performance related, but another reason why a clear all in a script might be a bad idea is that it will clear breakpoints (this can be annoying!), and global+persistent variables. However, it might be the goal to clear global and peristent variables. For global there's clear global, but there's nothing like that for persistent since persistent variables are bound to functions and you would use clear functions or clear whateverFunctionName for them.
I'm writing an application which will potentially be invoked by more than one launchd job – that is, there might be two distinct LaunchAgent .plist files which invoke the application with different program arguments or in different conditions. I'd like the application to be able to examine the job, or the job's .plist, so it can adjust its behaviour based on what it finds there.
In particular, supposing a program foo could be started up from both A.plist and B.plist, I'd like the program to be able to preserve different state depending on which job/plist invoked it. If all I can do is detect the (presumed distinct) Label of the job, that will be enough (though more would be better).
The obvious ways to do this are using different flags in the ProgramArguments array in the job, or to set different values in EnvironmentVariables, but both of those feel fragile, both imply duplication of bits of configuration, and both require extra documentation (“copy the value of the Label into EnvironmentVariables field FOO...; don't ask why”).
I can see the function SMJobCopyDictionary. With that, it appears that I can get access to the job's dictionary – ie, this information is available in principle – but I need to know the job's label first. Function SMCopyAllJobDictionaries allows me to iterate through all of the jobs, but it's not obvious how I'd find the one which invoked a particular instance of the application.
Googling launchd read job label or launchd self dict (or similar) don't come up with anything useful.
Take a look at the SampleD code on Apple's site. This code shows how daemon's can access calling launchd information.
Looking at the launch.h header, I suspect LAUNCH_JOBKEY_LABEL is what you are after.
Using the ProgramArguments is, in fact, probably the best way to handle this. It will make your code more portable (e.g. making it possible to launch in Linux, for example, or under a different launch daemon) to use program arguments that configure the behavior rather than relying on the program invocation chain.
With regard to program arguments, though, I would suggest not copying the label, but rather using the specific flags that differ between the jobs. For example, you might set --checkpoint-file and --log-file in both A.plist and B.plist to files that happen to include "A" or "B" in their names. Doing this will make the application code that depends on --checkpoint-file and --log-file much clearer, though, than if it were to make arbitrary choices based on some label and will also allow you to run the command directly from the commandline and have it still work despite there not being an invoking PLIST file.
Summary: I think the answer here is a qualified no.
Graham Miln's answer (which I've accepted) shows that this is possible in fact,
but the interface he mentions is apparently documented nowhere other than in
this sample code, and also possibly in Mac OS X Internals: A
Systems Approach (Amit Singh, http://osxbook.com, thanks to Mitchell J
Laurren-Ring for pointing this out).
I also asked about this on the launchd-dev list (see the thread starting with
my
question),
and Damien Sorresso suggested that this interface was “really only so that jobs
can check in with launchd to obtain listening sockets. They were way too general
at the outset.”
Put together, I'm left with the feeling that, while the behaviour I
want seems possible, and while I think it's neater in this case than
passing more state in environment variables, the API to support such
behaviour is, if not deprecated, than at least somewhat discouraged,
and at any rate not idiomatic.
Does anyone know of a Debugger or Programming Language that allows you to set a break point, and then modify the code and then execute the newly modified code.
This is even more useful if the Debugger also had the ability for reverse debugging. So you could step though the buggy code, stack backwards, fix the code, and then step though it again to see if you fixed the bug. Now that's sexy, is anyone doing this?
I believe the Hot Code Replace in eclipse is what you meant in the problem:
The idea is that you can start a debugging session on a given runtime
workbench and change a Java file in your development workbench, and
the debugger will replace the code in the receiving VM while it is
running. No restart is required, hence the reference to "hot".
But there are limitations:
HCR only works when the class signature does not change; you cannot
remove or add fields to existing classes, for instance. However, HCR
can be used to change the body of a method.
The totalview debugger provides the concept of Evaluation Point which allows user to "fix his code on the fly" or to "patch it" or to examine what if scenario without having to recompile.
Basically, user plants an Evaluation Point at some line and writes a piece of C/C++ or Fortran code he wants to execute instead. Could be a simple printf, goto, a set of if-then-else tests, some for loops etc... This is really powerful and time-sparing.
As for reverse-debugging, it's a highly desirable feature, but I'm not sure it already exists.
http://msdn.microsoft.com/en-us/library/bcew296c%28v=vs.80%29.aspx
The link is for VS 2005 but applies to 2008 and 2010 as well.
Edit, 2015: Read chapters 1 and 2 of my MSc thesis, Combining reverse debugging and live programming towards visual thinking in computer programming, it answers the question in detail.
The Python debugger, Pdb, allows you to run arbitrary code while paused (like at a breakpoint). For example, let's say you are debugging and have paused at the following line in your program, where the variable hasn't been declared in the program itself :
print (x)
so that moving forward (i.e., running that line) would result in :
NameError: name 'x' is not defined
You can define that variable in the debugger, and have the program continue executing with it :
(Pdb) 'x' in locals()
False
(Pdb) x = 1
(Pdb) 'x' in locals()
True
If you meant that the change should not be provided at the debugger console, but that you want to change the original code in some editor, then have the debugger automatically update the state of the live program in some way, so that the executing program reflects that change, that is called "live programming". (Not to be confused with "live coding" which is live performance of coding -- see TOPLAP -- though there is some confusion.) There has been an interest in research into live programming (and live coding) in the last 2 or 3 years. It is a very difficult problem to solve, and there are many different approaches. You can watch Bret Victor's talk, Inventing on Principle, for some examples of that. Note that those are prototypes only, to illustrate the idea. Hot-swapping of code so that the tree is drawn differently in the next loop of some draw() function, or so that the game character responds differently next time, (or so that the music or visuals are changed during a live coding session), is not that difficult, some languages and systems cater for that explicitly. However, the state of the program is not necessarily then a true reflection of the code (as also in the Pdb example above) -- if e.g. the game character could access an area based on some ability like jumping, and the code is then swapped out, he might never be able to access that area in the game any longer should the game be played from the start. To solve change propagation for general programming is difficult -- you can see that his search example re-runs the code from the start each time a change is made.
True reverse execution is also a tricky problem. There are a number of commercial projects, but almost all of them only record trace data to browse it afterwards, called omniscient debugging (but they are often called reverse-, back-in-time, bidirectional- or time-travel-debuggers, also a lot of confusion). In terms of free and open-source projects, the GNU debugger, gdb, has two modes, one is process record and replay which also only records the program for browsing it afterwards, the other is true reverse debugging which allows you to reverse in a live program. It is extremely slow, as it undoes single machine instruction at a time. The extended python debugger prototype, epdb, also allows for true reversing in a live program, and is much faster as it uses a snapshot/checkpoint and replay mechanism. Here is the thesis and here is the program and the code.
I am aware that this is nothing new and has been done several times. But I am looking for some reference implementation (or even just reference design) as a "best practices guide". We have a real-time embedded environment and the idea is to be able to use a "debug shell" in order to invoke some commands. Example: "SomeDevice print reg xyz" will request the SomeDevice sub-system to print the value of the register named xyz.
I have a small set of routines that is essentially made up of 3 functions and a lookup table:
a function that gathers a command line - it's simple; there's no command line history or anything, just the ability to backspace or press escape to discard the whole thing. But if I thought fancier editing capabilities were needed, it wouldn't be too hard to add them here.
a function that parses a line of text argc/argv style (see Parse string into argv/argc for some ideas on this)
a function that takes the first arg on the parsed command line and looks it up in a table of commands & function pointers to determine which function to call for the command, so the command handlers just need to match the prototype:
int command_handler( int argc, char* argv[]);
Then that function is called with the appropriate argc/argv parameters.
Actually, the lookup table also has pointers to basic help text for each command, and if the command is followed by '-?' or '/?' that bit of help text is displayed. Also, if 'help' is used for a command, the command table is dumped (possible only a subset if a parameter is passed to the 'help' command).
Sorry, I can't post the actual source - but it's pretty simple and straight forward to implement, and functional enough for pretty much all the command line handling needs I've had for embedded systems development.
You might bristle at this response, but many years ago we did something like this for a large-scale embedded telecom system using lex/yacc (nowadays I guess it would be flex/bison, this was literally 20 years ago).
Define your grammar, define ranges for parameters, etc... and then let lex/yacc generate the code.
There is a bit of a learning curve, as opposed to rolling a 1-off custom implementation, but then you can extend the grammar, add new commands & parameters, change ranges, etc... extremely quickly.
You could check out libcli. It emulates Cisco's CLI and apparently also includes a telnet server. That might be more than you are looking for, but it might still be useful as a reference.
If your needs are quite basic, a debug menu which accepts simple keystrokes, rather than a command shell, is one way of doing this.
For registers and RAM, you could have a sub-menu which just does a memory dump on demand.
Likewise, to enable or disable individual features, you can control them via keystrokes from the main menu or sub-menus.
One way of implementing this is via a simple state machine. Each screen has a corresponding state which waits for a keystroke, and then changes state and/or updates the screen as required.
vxWorks includes a command shell, that embeds the symbol table and implements a C expression evaluator so that you can call functions, evaluate expressions, and access global symbols at runtime. The expression evaluator supports integer and string constants.
When I worked on a project that migrated from vxWorks to embOS, I implemented the same functionality. Embedding the symbol table required a bit of gymnastics since it does not exist until after linking. I used a post-build step to parse the output of the GNU nm tool for create a symbol table as a separate load module. In an earlier version I did not embed the symbol table at all, but rather created a host-shell program that ran on the development host where the symbol table resided, and communicated with a debug stub on the target that could perform function calls to arbitrary addresses and read/write arbitrary memory. This approach is better suited to memory constrained devices, but you have to be careful that the symbol table you are using and the code on the target are for the same build. Again that was an idea I borrowed from vxWorks, which supports both teh target and host based shell with the same functionality. For the host shell vxWorks checksums the code to ensure the symbol table matches; in my case it was a manual (and error prone) process, which is why I implemented the embedded symbol table.
Although initially I only implemented memory read/write and function call capability I later added an expression evaluator based on the algorithm (but not the code) described here. Then after that I added simple scripting capabilities in the form of if-else, while, and procedure call constructs (using a very simple non-C syntax). So if you wanted new functionality or test, you could either write a new function, or create a script (if performance was not an issue), so the functions were rather like 'built-ins' to the scripting language.
To perform the arbitrary function calls, I used a function pointer typedef that took an arbitrarily large (24) number of arguments, then using the symbol table, you find the function address, cast it to the function pointer type, and pass it the real arguments, plus enough dummy arguments to make up the expected number and thus create a suitable (if wasteful) maintain stack frame.
On other systems I have implemented a Forth threaded interpreter, which is a very simple language to implement, but has a less than user friendly syntax perhaps. You could equally embed an existing solution such as Lua or Ch.
For a small lightweight thing you could use forth. Its easy to get going ( forth kernels are SMALL)
look at figForth, LINa and GnuForth.
Disclaimer: I don't Forth, but openboot and the PCI bus do, and I;ve used them and they work really well.
Alternative UI's
Deploy a web sever on your embedded device instead. Even serial will work with SLIP and the UI can be reasonably complex ( or even serve up a JAR and get really really complex.
If you really need a CLI, then you can point at a link and get a telnet.
One alternative is to use a very simple binary protocol to transfer the data you need, and then make a user interface on the PC, using e.g. Python or whatever is your favourite development tool.
The advantage is that it minimises the code in the embedded device, and shifts as much of it as possible to the PC side. That's good because:
It uses up less embedded code space—much of the code is on the PC instead.
In many cases it's easier to develop a given functionality on the PC, with the PC's greater tools and resources.
It gives you more interface options. You can use just a command line interface if you want. Or, you could go for a GUI, with graphs, data logging, whatever fancy stuff you might want.
It gives you flexibility. Embedded code is harder to upgrade than PC code. You can change and improve your PC-based tool whenever you want, without having to make any changes to the embedded device.
If you want to look at variables—If your PC tool is able to read the ELF file generated by the linker, then it can find out a variable's location from the symbol table. Even better, read the DWARF debug data and know the variable's type as well. Then all you need is a "read-memory" protocol message on the embedded device to get the data, and the PC does the decoding and displaying.