fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
pwithnall has quit [Ping timeout: 252 seconds]
<fche>
ooh I like it
<fche>
ship it
orivej has quit [Remote host closed the connection]
orivej has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
<agentzh>
fche: awesome :)
xar- has quit [Ping timeout: 260 seconds]
gregwork has quit [Ping timeout: 260 seconds]
gregwork has joined #systemtap
xar- has joined #systemtap
<agentzh>
fche: committed :) i'll update the remaining tests to use this new module.'
<fche>
& is not a c-like general operator here, it's punctuation for $context type variables only, like the $ suffix
<fche>
parenthesizing it imho would give people the wrong idea
<agentzh>
what's the disadvantage of making it more general?
orivej has quit [Ping timeout: 272 seconds]
<fche>
well, we can't really make it more general at the language level, we don't have a c-like abstract machine
<agentzh>
can we make this just an undocumented feature?
<agentzh>
without it, a stap code emitter is harder to write.
<fche>
what kinds of things does your emitter want to take addresses of ?
<agentzh>
i just want to always add parentheses to avoid any potential operator precedence problems.
slowfranklin has left #systemtap [#systemtap]
<fche>
but around what? the only things one can take addresses of are @var() and $foo target_symbols, which are not themselves expresssions
<fche>
so there isn't really a precedence problem AIUI
<agentzh>
for example, &(a + 1) should give the right stap compile-time error instead of becoming &a + 1.
<fche>
stap language is not C though, so it's not the 'right' error really
<agentzh>
but &(a) should be fine.
<agentzh>
the code emitter can simply add parentheses after `&` so that it does not have to care about what's inside.
<fche>
yeah but in stap land, very little -can- be inside
<agentzh>
sure, just want to make the parser a little bit more flexible.
<agentzh>
'&' does look like a unary operator anyway.
<fche>
ok, aside from all that ... for some reason this does parse in git stap:
<fche>
stap -p1 -e 'probe begin { print(&(1+a+1))}'
<fche>
which is just not right, so something in this area has already been played-with
<agentzh>
yeah, i just make the good case really work.
<agentzh>
so nothing to lose here?
<agentzh>
for bad cases, stap already gives good error messages.
orivej has joined #systemtap
<fche>
let's pause and let me figure out what's going on with this variant of '&'. our old pal jistone added support for it during the auto-@cast work four years ago
<fche>
commit 0fb0cac98ad4
<agentzh>
is jistone still around hacking on stap?
<fche>
not lately :)
* agentzh
misses him :)
<jistone>
I'm around, but not on stap, no
<jistone>
aww, thanks :)
<agentzh>
good to see you again
<jistone>
you too, looks like you're busy here lately
<agentzh>
indeed :)
<agentzh>
i've been hacking on stap in a full time fashion lately.
<agentzh>
keeping bombing fche with patches.
<fche>
agentzh, looking over the test cases in your patch, it seems to me they all already parse, thanks to that older work
<agentzh>
right, my change is really small :)
<agentzh>
just a couple of lines.
<fche>
what's an example & expression that requires your change?
orivej has quit [Ping timeout: 244 seconds]
<agentzh>
&(@var("a)) and &((@var("a")->foo)) ?
<agentzh>
those "good cases" using () after &.
<fche>
that parses for me
<agentzh>
but it does not run withotu my change.
<agentzh>
*without
<agentzh>
the AST is wrong.
<agentzh>
or parse tree
<fche>
& FOO gets a cast_op (FOO ....) generated
przemoc has joined #systemtap
<fche>
ah, I think I see what you mean.
<fche>
& (real_target_sym_expression) was not interpreted the same as real_target_sym_expression-with-addrof-flag
<agentzh>
without my patch, TEST 1 gives a confusing error message like this: semantic error: cannot take address of tracepoint variable: operator '&'
<agentzh>
for example.
<fche>
ok. so the NEWS blurb is a bit misleading.
<fche>
it should say parenthesis after & with a target-symbol expression is now accepted
<fche>
or something like that
<fche>
because as we discovered, jistone made &(stuff) work in other contexts already