printd[ln] cannot take a string variable as the first argument. probe begin { b = "," printd(b,"foo","bar") println("") exit() } stap a.stp parse error: expected string saw: identifier 'b' at a.stp:6:9 parse error: expected statement saw: a.stp EOF 2 parse error(s). Pass 1: parse failed. Try again with more '-v' (verbose) options. Also printd[ln] cannot handle case where there is only one values to print: probe begin { printd(",","foo") println("") exit() } stap a.stp parse error: expected ',' saw: operator ')' at a.stp:5:18 parse error: expected statement saw: a.stp EOF 2 parse error(s). Pass 1: parse failed. Try again with more '-v' (verbose) options. I have checked in testsuite/systemtap.printf/printd.stp and estsuite/systemtap.printf/printdln.stp to test all the edge cases that I think should work. They do not currently coimpile.
(In reply to comment #0) > printd[ln] cannot take a string variable as the first argument. > probe begin { > b = "," > printd(b,"foo","bar") > println("") > exit() > } Currently a call like printd(",", "foo", 42, "bar") gets synthesized into _stp_printf("%s,%d,%s", "foo", 42, "bar"). Using non-literal delimiters, would have to be instead: _stp_printf("%s%s%d%s%s", "foo", delim, 42, delim, "bar") Perhaps we could still optimize the literal case though. Do you really see a need to have non-literal delimiters? > Also printd[ln] cannot handle case where there is only one values to print: This is consistent with the documentation, which specifies "two or more values." > probe begin { > printd(",","foo") > println("") > exit() > } Why should we support this? If you only have one value, just use print[ln]. Using printd with one value would mean that you're specifying a delimiter that will just be ignored.
Subject: Re: printd and printdln broken On Thu, 2007-10-25 at 19:39 +0000, joshua dot i dot stone at intel dot com wrote: > ------- Additional Comments From joshua dot i dot stone at intel dot com 2007-10-25 19:39 ------- > (In reply to comment #0) > > printd[ln] cannot take a string variable as the first argument. > > probe begin { > > b = "," > > printd(b,"foo","bar") > > println("") > > exit() > > } > > Currently a call like printd(",", "foo", 42, "bar") gets synthesized into > _stp_printf("%s,%d,%s", "foo", 42, "bar"). Using non-literal delimiters, would > have to be instead: > _stp_printf("%s%s%d%s%s", "foo", delim, 42, delim, "bar") That looks fine to me. > Perhaps we could still optimize the literal case though. Why bother? I timed the above examples and measured their speed as identical within a few percent. Of course, if everything was a literal, we could do some serious optimization, but that case will likely never happen in real life. > Do you really see a need to have non-literal delimiters? It came up in some code I was writing, the first time I ever used printd. What about examples where you might want to specify the delimiter on the command line. I think it is also bad to have hidden requirements that some strings need be literals. > > > Also printd[ln] cannot handle case where there is only one values to print: > > This is consistent with the documentation, which specifies "two or more values." OK then. Forget that part. Martin
(In reply to comment #2) > > Perhaps we could still optimize the literal case though. > > Why bother? I timed the above examples and measured their speed as > identical within a few percent. I won't spend much time on it then, but if the optimization is easy, I'll do it. > What about examples where you might want to specify the delimiter on the > command line. printd(@1, "foo", "bar") works just fine. > I think it is also bad to have hidden requirements that some strings need > be literals. BTW, our printf also requires the format string to be a literal.
Subject: Re: printd and printdln broken On Thu, 2007-10-25 at 23:48 +0000, joshua dot i dot stone at intel dot com wrote: > ------- Additional Comments From joshua dot i dot stone at intel dot com 2007-10-25 23:48 ------- > (In reply to comment #2) > > > Perhaps we could still optimize the literal case though. > > > > Why bother? I timed the above examples and measured their speed as > > identical within a few percent. > > I won't spend much time on it then, but if the optimization is easy, I'll do it. > > > What about examples where you might want to specify the delimiter on the > > command line. > > printd(@1, "foo", "bar") works just fine. > > > I think it is also bad to have hidden requirements that some strings need > > be literals. > > BTW, our printf also requires the format string to be a literal. I did not realize that. Let's just document these limitations and spend our time on more important matters.
(In reply to comment #4) > I did not realize that. Let's just document these limitations and spend > our time on more important matters. OK, I noted the string literal limitations in the manpage and language reference.