I'd like to add a directory containing .ado files to the ado-path. This directory contains several subdirectories, corresponding to different projects. The .ado files are in these subdirectories.
However, when I type adopath + directory, commands in the .ado files are not recognized by Stata. I need to enter adopath + directory/subdirectory for each subdirectory. Is there a way around it?
Stata has a rule that in addition to the directories (etc.) explicitly named in the adopath, it will also look off those in subdirectories named by an individual letter for programs whose names begin with that letter.
Thus suppose you are invoking a command whatever and your named directories include c:\ado\plus. Stata's searches will include c:\ado\plus\w if that exists and a program file has not yet been found.
However, Stata doesn't promise to search in all subdirectories and it will pay attention to the initial letter of the program name.
Having .ado files specific to a project would best be accommodated by changing to the directory involved while working on that project. If you prefer not to do that, then you need to name specific directories fully if they don't match your adopath as extended by this single letter rule.
This is a matter of personal style, but I have never thought of any ados I wrote as specific to a particular project. Do-files yes, but not ados. But your project do-file might start with additions to the adopath and finish with reversing those.
Related
In our project we have the following directory structure:
gambit
gambit/Utils
gambit/Utils/include/gambit/Utils
gambit/Utils/src
gambit/Core
gambit/Core/include/gambit/Core
gambit/Core/src
...
and so on. We do this so that in our files we have a clean include structure, like this:
#include "gambit/Utils/somefile.hpp"
where we compile with -Igambit/Utils/include and so forth. Now I would like to add doxygen documentation for each level in this directory tree. But how can I do it? I seem to be unable to avoid warning: \dir command matches multiple directories. For example, say I want to document the root directory, I seem to have no choice but to write e.g.
/// \dir gambit
/// \brief Root of GAMBIT source tree
///
/// Some long description
However that gives me warning: \dir command matches multiple directories because it matches the root directory, as well as both of these directories:
gambit/Utils/include/gambit
gambit/Core/include/gambit
But this is the root directory of the project, I cannot add anything to the path name to make it unique, because there is nothing to add! The same problem exists for the gambit/Utils and gambit/Core ambiguities. Is there some way to tell doxygen to prefer shorter matches? Currently it just seems to pick randomly between its options. Documenting the other directories with their long names doesn't seem to help, it looks like doxygen doesn't use that information to go back and resolve earlier conflicts.
Following up on this question about including source files. I am including a Chapel modules that contains one file called classes.chpl, but my current project also has a classes.chpl. What is the correct disambiguation pattern? When I do
chpl -M/path/src
it notes the conflict, then chooses the classes.chpl in the current directory. Should I compile the module for export as in this page or is there another pattern.
== UPDATE ==
The directory structure looks like
projA/alpha.chpl
/classes.chpl
projB/beta.chpl
/classes.chpl
Where each project depends on the classes in the respective classes.chpl file. Trying to compile projA I am currently using
chpl alpha.chpl -M../projB/
But this causes a conflict, as it tries to use projA/classes.cphl for the classes in both beta.chpl and alpha.chpl.
As described in the module search paths tech note, the Chapel compiler searches for user modules by, in this order:
Looking at .chpl files specified on the command line
Looking at other .chpl files in the directories containing the files specified on the command line
Looking at .chpl files in the paths specified via the -M option or the CHPL_MODULE_PATH environment variable
Since the compiler finds the classes.chpl from the project directory using rule 2, and only finds the /path/src/classes.chpl with rule 3, it chooses the one in the project directory. To get it to choose /path/src/classes.chpl instead, you can specify it on the command line so it is found with rule 1.
chpl mainModule.chpl /path/src/classes.chpl
I use Stata 14.1 on Windows 8.1 and moved my personal .ado files to GitHub repositories. This put foo.ado in "C:/Users/Richard/Documents/GitHub/foo/", bar.ado in "C:/Users/Richard/Documents/GitHub/bar/", and so on.
I added the GitHub root directory to adopath with adopath + "C:/Users/Richard/Documents/GitHub/", but Stata did not search "foo", "bar", and other sub-directories for .ado files. I fixed this by adding the foo.ado repository with adopath + "C:/Users/Richard/Documents/GitHub/foo", and so on.
I expected Stata to search "C:/Users/Richard/Documents/GitHub/" recursively because it does so for BASE, SITE, and PLUS. Is recursive searching limited to the default adopath directories?
To be fair, it isn't difficult to add a ten directories to adopath, but I want to follow best practices. I can't find much about adopath other than help adopath and this 1996 FAQ.
Stata doesn't exactly recursively search BASE, SITE, and PLUS. It searches each directory, and within the directory, will search in exactly one subdirectory having as its name the first letter of the command being searched for.
Within PERSONAL, I created the subdirectory f and placed within it foo.ado. When I typed the command foo into Stata's Command window, Stata found foo.ado and ran the program within.
This doesn't directly solve your problem, but it does show that Stat treats PERSONAL consistently with the other directories, reducing the likelihood of convincing StataCorp to implement your suggestion, but confirming that your workaround seems to be "best practices" such as they are.
On my Mac, I renamed the directory f to gnxl and then, in a terminal window
cd ~/Library/Application Support/Stata/ado/personal
ln -s gnxl/foo.ado .
after which, having exited and relaunched Stata, the foo command performed as expected. Perhaps this points a direction for you, with some automation to generate the symbolic links as new ado files are created in your repository. I don't know enough GitHub to know if that is possible within its framework.
I'm using the following code from this website about how to read from a folder to get all the files. I'm then "pushing" them into a string vector.
My question is, when I read all the files, I get "." and ".." as my first to "files" read from the folder; what are these two "files"?
Furthermore, this code does achieve the goal. I'm just curious as to what these two "files" really are.
I'm using Xcode, and this is in C++.
Let me know if you need more info.
In linux and unix there is no difference between a file and a directory. Note that in the case of these dot files they are actually not "real files" though, that's another topic.
The "." is a special file in the folder which means "the current directory" and ".." is another special file which means "the parent directory".
Directories do not contain files. Directories contain names. The names are links to objects in the filesystem. The names . and .. are links to the directory and its parent, respectively.
I'm just getting my feet wet in C++ using the Stanford CS 106B lectures available online. The assignments have the students use some custom libraries which are available for download online, although the installation instructions are gone.
While I can do the assignments in Xcode using a pre-built blank project which includes the relevant files and source trees set up, I also have TextMate on hand and thought I'd like to try coding with it, since I liked using it a lot for coding LaTeX. So far so good.
The first program I'm trying to run (a very simple ten-line program) contains an # include "genlib.h" in the first line. I have the genlib.h file, but can't seem to get either of the following to work:
Add the path to the relevant file in TextMate: When I try to add the path to the folder on my desktop (/previouspathinthelist:/Users/me/Desktop/C++\ libraries) where the file lives I get an error: /Users/me/Documents/c++ programs/powertab.cpp:9:20: error: genlib.h: No such file or directory even though the file is right there! (Maybe I should note here that the file to be imported and the program file are in two different folders).
Add the file to one of the other paths: I can't move the files using mv in terminal to usr/bin, usr/sbin, etc. because it says I don't have the proper permissions.
Is there something I'm doing wrong in setting my path to my folder in Documents? There aren't any spelling mistakes or anything since the path came straight from get info in the finder. I know this is a programming forum and not a TextMate support forum, but I thought it'd be good to know where people generally put these kinds of files on their systems.
Just put the file in the same directory as your other source files.
#include "filename"
searches the source directory first, whereas
#include <filename>
only searches the include file path.
The reason why /previouspathinthelist:/Users/me/Desktop/C++\ libraries doesn't work probably has to do with the space in the file name. It is quite possible that a backslash is not the right way to quote the space in the tool you're using. Many tools from the C/unix tradition deal rather badly with pathnames that contain space (even though the Unix kernel itself has no such problem); often you'll find that there is no single amount of quoting that will simultaneously satisfy all the tools and subsystems that use some setting. Better to avoid spaces in filenames entirely when you're doing development.