Say I remember a constant or theory name, but totally forgot where it is declared. Perhaps, I don't even know in which MMT archive it is declared. How can I find out the source file?
Can I just open an MMT shell, load all archives I have on my disk, and issue some command find_constant <constant name>? Does such a command exist?
It depends on what you know about the thing whose declaration point you seek:
If you don't know anything, i.e. if you don't even have a typechecking file where the thing is used.
Then the easiest way to find out the point of declaration is to just grep over all *.mmt files with regexes. For (typed) constants, use <constant name>\s*?:. It will match constant declarations, followed by some optional whitespace, and a colon.
With Notepad++, this is easy to do. Say, you wanted to know where congT is declared. Then you would do:
You have a typechecking MMT file where the thing you are looking for is used.
Then use the MMT IntelliJ plugin and its document tree: first typecheck the file at hand, and then look in the sidekick for the occurrence of the constant:
Activating the Navigate option is particularly helpful here: with that you can simply click with your mouse on the thing whose point of declaration you seek (here e.g. nat_lit) and immediately have it revealed in the sidekick. Here, the sidekick shows nat_lit (?NatLiterals) meaning that the constant was defined in the theory NatLiterals. Ideally, you know where that theory is declared.
In theory, you could also control-click on the constant, but that doesn't currently work for reasons beyond my knowledge.
Related
Now I'm trying to use .dir-locals.el for my own projects.
However it is saved at the end of init.el whenever I choose to save it permanently.
I'd like to change it to an another seperate file - eg ~/mydirlocals.el.
Please let me know what could be the solution for this.
PS : I've already tried to change custom file to a seperate one. But unfortunately it saved my dir-local variables with other custom variables.
I want to avoid this and save my dir-locals variables in a completely seperate file.
You can't use the customize interface to update .dir-locals.el files. Customize is for your own config. If you want to edit/update a directory-local variables file, you need to either edit that file directly, or use M-x add-dir-local-variable.
The latter command will prompt you for the details. Note that no default value is offered at the prompt for the value of the variable, but that you can type M-n or <down> to obtain the variable's value in the current buffer.
Note also that the command does not ask which directory the variables are local to -- it will create/update a .dir-locals.el file in the default directory for the current buffer. Issuing the command from a dired buffer for the intended directory is a safe approach, naturally, but you may wish to do so from a buffer in the mode for which you wish to add variables -- that way the default suggestion for the mode, and the current values of the variables in question, will be more useful to you.
(If there is no file of the appropriate type in the directory, you can always C-xC-f a new/unsaved buffer of an appropriate filename, use add-dir-local-variable as many times as necessary, and then when you're done just kill any new buffers you created without saving them.)
That all said, I'm still not 100% sure what your requirement is, as your question is a little confused; but you may also like to know that you can use directory-local variables without a .dir-locals.el file at all, as you can alternatively configure them entirely in your init file.
See https://www.emacswiki.org/emacs/DirectoryVariables for details and examples of that.
Disclaimer: I haven't used dir-local vars, but I have used file-local vars. I'm guessing dir-locals work the same.
The local variables aren't getting saved at the end of init.el or custom.el, the safe values are. As in, Emacs doesn't trust them by default, unless they match some sort of predicate indicating they're OK. This is a good policy, because file and dir locals can cause Emacs to run arbitrary code just by opening a file. When you apply permanently, you're telling Emacs that that value is safe; it basically just makes a predicate that matches the exact value and stores that with customize.
If you want to prevent the prompt (and thus the saving), you need mark the variables as safe with your own predicate.
For example, I set
(put 'adaptive-wrap-extra-indent 'safe-local-variable 'integerp)
which means that adaptive-wrap-extra-indent is OK as long as it's an integer. I know this is OK because I added that variable to the adaptive-wrap package (though I didn't know about safe locals at the time; I submitted a bug to fix it, which appears to be ignored). Clearly you can use any predicate, including (lambda (x) t), though I'd recommend against that.
Looking at CMake documentation for the command line options, there's some ambiguity in the -D option used to define a variable.
In the command line synopsis there's
-D<var>=<value>
While in the option description we read:
-D <var>:<type>=<value>
The two entries differ by a space between -D and the variable definition, and by the presence/absence of :<type>.
Does the space make any difference? What is the difference between specifying or not the type? Is it cached in any case?
From a quick test, it seems the space is optional. While if the variable type is not specified, the variable goes in CMakeCache.txt as:
//No help, variable specified on the command line.
MYVARIABLENAME:UNINITIALIZED=MYVARIABLEVALUE
And it will not appear in the cache of cmake-gui.
Are these behaviours documented anywhere?
Edit:
I have reported an issue in CMake bug tracker. As visible in the link, it seems that some solution was already on its way, and documentation should be fixed for CMake 3.3!.
I don't believe the behaviour you're seeing is documented, but your conclusions are generally correct.
If the type is not specified, then the cached entry has type UNINITIALIZED. Since CMake isn't a strongly-typed language, you can use this variable as any type you require within the CMakeLists.txt - a string, path, list, etc. However, unless you explicitly change the type in your CMakeLists.txt (e.g. using a set call) its type will remain UNINITIALIZED as far as the cached value goes.
As far as I know, the type is really only useful if you're using the CMake GUI so it can appropriately choose which sort of input box to use for the variable, or whether to show it to the user at all or not.
As for the space - this is a more awkward situation. I have another answer which goes into this in a bit of detail, but basically, the space should have no effect, but it does under certain circumstances. I recommend not putting a space after -D arguments.
I've used simple makefiles for years, but only recently been assigned the task of learning the ins and outs of a large, complicated set of Autotools-generated makefiles which is used for a code base my employer has bought. In these, I'm running into variable declarations like the following:
QOBJECT_MOCSRCS = $(QOBJECT_HEADER:%.h=.gen/moc_%.cpp) \
$(QOBJECT_SRCS:%.cpp=.gen/moc_%.cpp)
QOBJECT_DEPS = $(QOBJECT_MOCSRCS:%.cpp=.deps/%.Po)
My best guess from context is that these set up lists of names of files to be provided by the build process, eg., QOBJECT_MOCSRCS should end up as a list of (a) .h files, (b) .cpp files, based on the % stem names of a set of intermediate .cpp files which will be generated during the build, in a temporary directory ./gen. This is used to store the moc_%.cpp files which are output as a result of a build of Qt files with Qt's moc tool...what is driving me crazy, is that I have been unable to find anything in any make documentation I've got (mostly the GNU make manual) that tells me what this style of declaration is called, so I can track it down and get a grip on the syntax. The contents of the $() look sort of like rules, and the nearest equivalents in the GNU make manual seem to be rules specifying target-specific variable values, but I have no idea whether this is anywhere near a correct reading. Can anyone point me to an appropriate reference for study?
This feature is called substitution references, http://www.gnu.org/software/make/manual/html_node/Substitution-Refs.html#Substitution-Refs
How can you trace function calls, DEFINEs and declarations in a complex project from the listed includes in a given file using gedit?
In other IDEs you usually right-click on a function or variable and it can take you to its original declaration.
Gedit is an extremely light text editor and not an IDE. Therefore to answer you,
It is not possible to do what you are asking in Gedit. It never "reads" your code per se (IDEs/compliers do this) and hence can't locate function definitions etc.
I'm producing a hex file to run on an ARM processor which I want to keep below 32K. It's currently a lot larger than that and I wondered if someone might have some advice on what's the best approach to slim it down?
Here's what I've done so far
So I've run 'size' on it to determine how big the hex file is.
Then 'size' again to see how big each of the object files are that link to create the hex files. It seems the majority of the size comes from external libraries.
Then I used 'readelf' to see which functions take up the most memory.
I searched through the code to see if I could eliminate calls to those functions.
Here's where I get stuck, there's some functions which I don't call directly (e.g. _vfprintf) and I can't find what calls it so I can remove the call (as I think I don't need it).
So what are the next steps?
Response to answers:
As I can see there are functions being called which take up a lot of memory. I cannot however find what is calling it.
I want to omit those functions (if possible) but I can't find what's calling them! Could be called from any number of library functions I guess.
The linker is working as desired, I think, it only includes the relevant library files. How do you know if only the relevant functions are being included? Can you set a flag or something for that?
I'm using GCC
General list:
Make sure that you have the compiler and linker debug options disabled
Compile and link with all size options turned on (-Os in gcc)
Run strip on the executable
Generate a map file and check your function sizes. You can either get your linker to generate your map file (-M when using ld), or you can use objdump on the final executable (note that this will only work on an unstripped executable!) This won't actually fix the problem, but it will let you know of the worst offenders.
Use nm to investigate the symbols that are called from each of your object files. This should help in finding who's calling functions that you don't want called.
In the original question was a sub-question about including only relevant functions. gcc will include all functions within every object file that is used. To put that another way, if you have an object file that contains 10 functions, all 10 functions are included in your executable even if one 1 is actually called.
The standard libraries (eg. libc) will split functions into many separate object files, which are then archived. The executable is then linked against the archive.
By splitting into many object files the linker is able to include only the functions that are actually called. (this assumes that you're statically linking)
There is no reason why you can't do the same trick. Of course, you could argue that if the functions aren't called the you can probably remove them yourself.
If you're statically linking against other libraries you can run the tools listed above over them too to make sure that they're following similar rules.
Another optimization that might save you work is -ffunction-sections, -Wl,--gc-sections, assuming you're using GCC. A good toolchain will not need to be told that, though.
Explanation: GNU ld links sections, and GCC emits one section per translation unit unless you tell it otherwise. But in C++, the nodes in the dependecy graph are objects and functions.
On deeply embedded projects I always try to avoid using any standard library functions. Even simple functions like "strtol()" blow up the binary size. If possible just simply avoid those calls.
In most deeply embedded projects you don't need a versatile "printf()" or dynamic memory allocation (many controllers have 32kb or less RAM).
Instead of just using "printf()" I use a very simple custom "printf()", this function can only print numbers in hexadecimal or decimal format not more. Most data structures are preallocated at compile time.
Andrew EdgeCombe has a great list, but if you really want to scrape every last byte, sstrip is a good tool that is missing from the list and and can shave off a few more kB.
For example, when run on strip itself, it can shave off ~2kB.
From an old README (see the comments at the top of this indirect source file):
sstrip is a small utility that removes the contents at the end of an
ELF file that are not part of the program's memory image.
Most ELF executables are built with both a program header table and a
section header table. However, only the former is required in order
for the OS to load, link and execute a program. sstrip attempts to
extract the ELF header, the program header table, and its contents,
leaving everything else in the bit bucket. It can only remove parts of
the file that occur at the end, after the parts to be saved. However,
this almost always includes the section header table, and occasionally
a few random sections that are not used when running a program.
Note that due to some of the information that it removes, a sstrip'd executable is rumoured to have issues with some tools. This is discussed more in the comments of the source.
Also... for an entertaining/crazy read on how to make the smallest possible executable, this article is worth a read.
Just to double-check and document for future reference, but do you use Thumb instructions? They're 16 bit versions of the normal instructions. Sometimes you might need 2 16 bit instructions, so it won't save 50% in code space.
A decent linker should take just the functions needed. However, you might need compiler & linke settings to package functions for individual linking.
Ok so in the end I just reduced the project to it's simplest form, then slowly added files one by one until the function that I wanted to remove appeared in the 'readelf' file. Then when I had the file I commented everything out and slowly add things back in until the function popped up again. So in the end I found out what called it and removed all those calls...Now it works as desired...sweet!
Must be a better way to do it though.
To answer this specific need:
•I want to omit those functions (if possible) but I can't find what's
calling them!! Could be called from any number of library functions I
guess.
If you want to analyze your code base to see who calls what, by whom a given function is being called and things like that, there is a great tool out there called "Understand C" provided by SciTools.
https://scitools.com/
I have used it very often in the past to perform static code analysis. It can really help to determine library dependency tree. It allows to easily browse up and down the calling tree among other things.
They provide a limited time evaluation, then you must purchase a license.
You could look at something like executable compression.