I've been using a macro library so that I can use macros without compiling them first. The problem is that when I change the macro and save it, then refresh my filename for the macro lib, this is not enough to update and use the new macro?
Anyone have any ideas why it is still using and compiling the old macro before it was saved?
The first time a macro is called, if it hasn't already been defined, SAS will check your autocall path and iterate through those locations trying to find it.
When it finds the macro in your autocall library it compiles it and saves the compiled version to your work folder. Subsequent calls to the macro will result in SAS using the compiled version of the macro.
In order for it to be refreshed (if you have made changes since it was compiled) you need to open the code to the macro and submit it again. That will redefine/recompile it for you.
Alternatively, you could also find the catalog in your work folder that contains the compiled versions of the macros and delete it from there (typically work.sasmacr).
Robert explains why you see the behavior.
I use the following to easily reinclude a changed macro. This assumes you have a FILENAME called MACROREF defined to the folder in question.
%include MACROREF(my_macro);
Obviously change the my_macro to the macro you need to be compiled.
filename macroref "c:\temp";
%include MACROREF(MacroOne);
If you have a folder full of macros (as stated in the comments) you can include the whole folder.
%include "%sysfunc(pathname(MACROREF))/*.sas";
This will recompile the whole folder. Just don't have any non-macro sas files in that folder, otherwise you are running them too.
Related
I remember that there's a ".txt" file which allows to define link/compile-time arguments, but I've forgotten it's name.
I tried to google for answer.
The text file is called compile_flags.txt.
It's discussed at https://clangd.llvm.org/installation#compile_flagstxt.
Note that there are some shortcomings of compile_flags.txt compared to the more common way of configuring a project for use with clang-based tooling, compile_commands.json; most notably, clangd won't index your project with compile_flags.txt.
For example, in my main.scm file I have (load "util.scm"). util.scm is a file in the same folder as main.scm. Both files are located in ~/documents/myproject/.
Now when I'm in this directory, and I run $ chez-scheme main.scm everything works fine. However, if I'm in my home directory and run $chez-scheme documents/myproject/main.scm it complains, not being able to find the file util.scm. I suppose this is the case because the current directory was my relevant home directory, and as such util.scm is indeed not there, it is actually in documents/myproject/. That being said, I'm used (in other languages) to the functionality of looking these paths up relative to the file containing the instruction to import, and I'd like to have that here as well. I've tried prefixing it by ./ or defining the file as a libary and doing (import (util)) but none of it works outside of documents/myproject/. Is there any way to get this to work as I intend it to?
I assume this is Chez-Scheme-specific. If not I'd prefer an answer that is implementation-neutral.
load is kind of awkward in R5RS since the report states that system interfaces are off topic in the report, but they include load which is a half hearted solution. The report does not say if the load is relative to the current directory or the file the load form originates from so in order to be portable I guess you are required to run your script from the current directory and have your loaded file relative to both.
Since Chez Scheme implements R6RS load is not really the right form to use. R6RS removed load in favor of libraries. You should make your file a library and consult how to install it. In some systems that is just placing the files in the right path, adding library location in configuration or running install script. How one uses the library is the same in all implementations, by using import.
According to Chez documentation you can pass --libdirs to it to give it one or more paths to consider for loading libraries. You can see the paths it scans by evaluating (library-directories)
There are several different ways to accomplish what (I think) you are trying to do, but eventually they all boil down to letting Chez know where to look for things. When given relative paths, include and load use the source-directories parameter to search for the requested file. Libraries have their path automatically prepended to source-directories while they are being loaded or compiled, so if your main.scm were a library definition then it would find util.scm as you expect.
However, it sounds like main.scm isn't a library, it's a top-level program. Unfortunately, Chez doesn't have a command line option to set the source-directories like it does for library directories. That leaves you with a bit less flexibility. Any of the following will work:
Make util.scm a library and invoke Chez with the --libdirs option to let it know where to look for libraries.
Set source-directories and load main.scm from inside the REPL rather than from the command line.
Write a wrapper shell script that does the above by echoing the commands into scheme so you don't have to type it yourself. (Only suitable if you don't also need to then type into the scheme session).
Write a wrapper shell script that cds into your project directory before running scheme (and presumably cds back to the original directory when it's done).
I'm using Doxygen to generate documentation for some code. I have a large makefile with a lot of OPT+=-DSOME_OPTION that I want to Doxygen to take into account when it analyses the code, since parts of the code are conditionally compiled.
I know there is a an option PREDEFINED in the Doxygen configuration file that specifies macro names that are defined for the preprocessor, but I do not want to manually update this list every time a change happens in the makefile. In essence I want to set the PREDEFINED option to scan the makefile for compilation definitions and be automatically updated.
Is this possible with Doxygen?
Let's say one file is compiled and is in running mode and it is using some macro.Is there any way to check what value of the macro that is being used by the file.
eg if the file contains
-define(TIMEOUT,200).
From terminal how can i check what TIMEOUT definition is being used by the file.
Why I want is because suppose file is in running mode and i changed the macro definition in between and forgot to compile the file. I want to confirm what defintion it is taking.
Macros do not survive even the earliest stages of the compilation as the preprocessor substitutes them immediately in the source. You will have to define and export a separate function to see their values, something like:
macro_values() ->
[{'TIMEOUT',?TIMEOUT},...].
You can then call this from the shell and get the values that were substituted.
Does the LISP program need to be in the same folder as the LISP compiler or can I call it from anywhere?
The basic operation is to call load with a pathname.
(load #p"/home/user710086/foo.lisp")
Then, you may need to run whatever "main" function is supplied by that file.
The location can also be in the current directory, which is, of course, platform dependent. The current directory usually has nothing to do with the directory the Lisp executable resided in, but is the directory of the shell you called it from. I do not know what the current directory is in Windows when you click on something, but I would guess that it is some home-directory-surrogate.
There are several things that may wrap around that basic operation. Usually, code is organized into an ASDF system, and has defined one or more packages. You would then add the .asd file to asdf:*asdf-registry* and then load the package with
(asdf:load-sys 'foo)
This would load all files defined in the .asd file in a calculated order, thus providing you with the system's functionality.