How do I define a macro with the same name as its expansion in m4? - recursion

I am attempting to replace if with if( using GNU m4 1.4.14 and I am receiving ERROR: end of file in argument list
when trying:
define(`if', `if(')
define(`then', `){')
define(`fi', `}')
if foo then bar() fi
I have tried escaping the parentheses but that caused m4 to error after a brief period of time saying it's out of memory. Scanning through the manual, I found nothing related to this problem.
Upon changing the name of the macro to 'IF' or something other than 'if', it works as expected, which leads me to believe it's evaluating itself repeatedly.
If so, how can I define a macro that is evaluated only once? Otherwise, what should I look into to fix this?
EDIT I found a way around this issue by processing twice, once to convert if to _IF and the next to convert _IF to if(. I assume there's a better way to do this, so this is only a temporary solution in my eyes.

You need to prevent m4 from attempting to re-expanding the replacements. Do so by double quoting:
define(`if', ``if('')
define(`then', `){')
define(`fi', `}')
if foo then bar() fi

Related

What is the difference between ?matrix and ?matrix()

I was going through swirl() again as a refresher, and I've noticed that the author of swirl says the command ?matrix is the correct form to calling for a help screen. But, when I run ?matrix(), it still works? Is there a difference between having and not having a pair of parenthesis?
It's not specific to the swirl environment (about which I was entirely unaware until 5 minutes ago) That is standard for R. The help page for the ? shortcut says:
Arguments
topic
Usually, a name or character string specifying the topic for which help is sought.
Alternatively, a function call to ask for documentation on a corresponding S4 method: see the section on S4 method documentation. The calls pkg::topic and pkg:::topic are treated specially, and look for help on topic in package pkg.
It something like the second option that is being invoked with the command:
?matrix()
Since ?? is actually a different shortcut one needs to use this code to bring up that page, just as one needs to use quoted strings for help with for, if, next or any of the other reserved words in R:
?'?' # See ?Reserved
This is not based on a "fuzzy logic" search in hte help system. Using help instead of ? gets a different response:
> help("str()")
No documentation for ‘str()’ in specified packages and libraries:
you could try ‘??str()’
You can see the full code for the ? function by typing ? at the command line, but I am just showing how it starts the language level processing of the expressions given to it:
`?`
function (e1, e2)
{
if (missing(e2)) {
type <- NULL
topicExpr <- substitute(e1)
}
#further output omitted
By running matrix and in general any_function you get the source code of it.

Open code statement recursion detected during exporting a file

I try to export a file in SAS but I get "Open code statement recursion detected." error. Since I export more than one files depending on date I define as a macro variable based on the prompt date, I want to name my file to be exported with this variable but it does not work. I would really appreciate if anyone helps me.
rep_date = 30APR2015:00:00:00
Outfile = work.A042015.sas7
%let var = CATS("A",MONTH(DATEPART(&rep_date)),YEAR(DATEPART(&rep_date)));
data WORK.&var(compress=yes); 
set WORK.have;
run; 
Macro variables are just strings. So if you want to execute functions in macro code you need to wrap the function inside of the %SYSFUNC() macro function.
%let rep_date='01JAN2015:01:23'dt ;
%let dsname = A%sysfunc(datepart(&rep_date),monyy6);
data &dsname(compress=yes);
set have;
run;
As a more broad issue, OPEN STATEMENT RECURSION DETECTED refers to cases where you assign a macro variable to itself.
%let &mvar = &mvar;
Of course, this wouldn't normally happen on purpose (one would think). When it does happen, usually it's a sign of one of two classes of mistake.
You're missing a semicolon, end parenthesis, end quote, or something else that causes SAS to not "see" the semicolon at the end of the %let statement. Then your next statement uses the macro variable in a macro context, and SAS sees that as part of the %let statement, which causes this error message.
Something went wrong somewhere else, and you have an issue where that something-else propagates errors further down that don't make any sense. Having an unmatched quotation is a classic example of this, as is a macro that doesn't properly %mend.
1 can happen in cases as simple as this:
%let mvar=mydataset
%put &mvar;
Oops. If it's that simple, then just pop the semicolon on and you're good. It could, however, be caused by something more significant - such as an unmatched parenthesis or quotation - which might require restarting your SAS session. (Sometimes submitting a magic string, which are variations on %*;*;*';*";%*%mend;*);, will fix things, sometimes not. Restarting SAS is a reliable way to fix that).
That's also true with 2 above - if a magic string doesn't fix it, then you may simply need to restart your SAS session. Of course, you still need to find that unmatched quote/parenthesis/etc., but you first need to start SAS over so you can figure it out.

/usr/bin/Rscript: Argument list too long

Using rscript inside a bash script
I am passing the content of text files has arguments. to rscript
"$SCRIPTS/myscript.R" "$filecontent"
I get the following when file have +- over 4000 row
/usr/bin/Rscript: Argument list too long
Any way I can increase the length of accepted argument so I can pass large files?
What #MrFlick said is correct - you should change the way the arguments are passed to your script. However, if you still want to try to do it your way, then I recommend reading the following article:
"Argument list too long": Beyond Arguments and Limitations
The "Argument list too long" error, which occurs anytime a user feeds
too many arguments to a single command, leaves the user to fend for
oneself, since all regular system commands (ls *, cp *, rm *, etc...)
are subject to the same limitation. This article will focus on
identifying four different workaround solutions to this problem, each
method using varying degrees of complexity to solve different
potential problems.
Also, this Unix&Linux thread can help:
“Argument list too long”: How do I deal with it, without changing my command?

gdb: logging something instead of breaking?

Is it possible to have gdb log something to the terminal instead of breaking on it? For example I would like to set a 'breakpoint' on some method and have gdb print self as well as the parameters each time the method is invoked. Basically I want to insert print statements into arbitrary places without actually recompiling.
thanks for any suggestions
This is what i have so far after these helpful comments:
define logFoo
b fooMethod
commands
po self
end
end
GDB doesn't seem to like the nested end statements though. any thoughts?
You can use Breakpoint Command Lists. There is an example how to do it.
For example, here is how you could use
breakpoint commands to print the value
of x at entry to foo whenever x is
positive.
break foo if x>0
commands
silent
printf "x is %d\n",x
cont
end
Use a breakpoint as usual, and set a macro to log and continue:
define c
print "foo"
cont
c
end
No, this is not possible. You can only hook into the symbols of the code and machine code. If you want to log output you will need a logging functionality.
If you are tracing specific errors try conditional breakpoints and watch variables.
EDIT:
Even while not directly loggin it could be an alternative to use GDB command files

Pass unevaluated commands to a function in R

I am a bit of an R novice, and I am stuck with what seems like a simple problem, yet touches pretty deep questions about how and when things get evaluated in R.
I am using Rserve quite a bit; the typical syntax to get things evaluated remotely is a bit of a pain to type repeatedly:
RSeval(connection, quote(try(command)))
So I would like a function r which does the same thing with just the call:
r(command)
My first, naive, bound to fail attempt involved:
r <- function(command) {
RSeval(c, quote(try(command)))
}
You've guessed it: this sends, literally, try(command) to my confused Rserve daemon. I want command to be partially evaluated, if that makes any sense -- i.e. replaced by what I typed as an argument, but without evaluating it locally.
I looked for solutions to this, browsed throught the documentation for quote, substitute, eval, call, etc.. but I was not able to find something that worked. Either command gets evaluated locally, or not at all.
This is not a big problem, I can type the whole damn quote(try()) thing all the time; but at this point I am mostly curious as to how to get this to work!
EDIT:
More explanations as to what I want to do.
In the text above, command is meant to be a call do a function, ideally -- i.e., not a character string. Something like a <- 3 or assign("a", 3) rather than "a<-3" or quote(a<-3).
I believe that this is part of what makes this tricky. It seems really hard to tell R not to evaluate this locally, but only send it literally. Basically I would like my function to be a bit like quote(), which does not evaluate its argument.
Some explanation about my intentions. I wish to use Rserve frequently to pass commands to a remote R daemon. The commands would be my own (or my colleagues) and the daemon protected by firewall and authentication (and would not be run as root) -- so there is no worry of malicious commands being passed.
To be perfectly honest, this is not a big issue, and I would be pretty happy to always use the RSeval(c, quote(try())). At this point I see this more like an interesting inquiry into the subleties of R :-)
You probably want to use the substitute command, it can give you the argument unevaluated that you can build into the call.
I'm not sure if I understood you correctly - would eval(parse(text = command)) do the trick? Notice that command is a character, so you can easily pass it as a function argument. If I'm getting the point...
Anyway, evaluating user-specified commands is potentially malicious, therefore not recommended. You should either install AppArmor and tweak it (which is not an easy one), or drop the whole evaluation thing...

Resources