fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
bchrisman has quit [Quit: Leaving.]
wcohen has joined #systemtap
hpt has joined #systemtap
cbzx has joined #systemtap
cbzx has quit [Client Quit]
<irker033> systemtap: wcohen systemtap.git:refs/heads/master * release-2.9-143-g2ed848e / doc/tutorial.tex systemtap.spec: Eliminate the use of tex(nomencl.sty) in TeX documentation files http://tinyurl.com/q2kbdju
ananth has joined #systemtap
hpt has quit [Read error: Connection reset by peer]
<fche> thanks will!
cbzx has joined #systemtap
hpt has joined #systemtap
hpt has quit [Ping timeout: 246 seconds]
captainhindsight has joined #systemtap
hpt has joined #systemtap
fche has quit [Remote host closed the connection]
fche has joined #systemtap
captainhindsight has quit [Quit: Page closed]
bchrisman has joined #systemtap
irker033 has quit [Quit: transmission timeout]
ego has joined #systemtap
naveen has joined #systemtap
srikar_away is now known as srikar
cbzx has quit [Quit: Konversation terminated!]
Humble has quit [Read error: Connection reset by peer]
Humble has joined #systemtap
hpt has quit [Ping timeout: 250 seconds]
mjw has joined #systemtap
modem has quit [Remote host closed the connection]
nkambo has joined #systemtap
ego has quit [Ping timeout: 255 seconds]
scox has quit [Ping timeout: 250 seconds]
modem has joined #systemtap
srikar is now known as srikar_away
naveen has quit [Quit: Leaving.]
ego has joined #systemtap
wakatana2 has joined #systemtap
ananth has quit [Ping timeout: 264 seconds]
wcohen has quit [Ping timeout: 260 seconds]
fLiPr3VeRsE has joined #systemtap
ananth has joined #systemtap
drsmith has joined #systemtap
scox has joined #systemtap
scox has quit [Client Quit]
scox has joined #systemtap
mbenitez has joined #systemtap
mbenitez has joined #systemtap
tromey has joined #systemtap
wcohen has joined #systemtap
mbenitez has quit [Ping timeout: 244 seconds]
mbenitez has joined #systemtap
ananth has quit [Quit: Leaving]
srikar_away is now known as srikar
naveen has joined #systemtap
brolley has joined #systemtap
bchrisman has quit [Quit: Leaving.]
srikar is now known as srikar_away
ego has quit [Ping timeout: 240 seconds]
bchrisman has joined #systemtap
mjw has quit [Quit: Leaving]
naveen has quit [Quit: Leaving.]
ldng has joined #systemtap
mbenitez has quit [Quit: To office]
Humble has quit [Ping timeout: 272 seconds]
Humble has joined #systemtap
mjw has joined #systemtap
mbenitez has joined #systemtap
bchrisman has quit [Quit: Leaving.]
cbzx has joined #systemtap
nkambo has quit [Remote host closed the connection]
bchrisman has joined #systemtap
drsmith is now known as drsmith_away
bchrisman has quit [Quit: Leaving.]
tromey has quit [Quit: ERC (IRC client for Emacs 25.1.50.1)]
cbzx has quit [Ping timeout: 255 seconds]
mjw has quit [Quit: Leaving]
ldng has quit [Quit: Leaving]
cbzx has joined #systemtap
bchrisman has joined #systemtap
scox has quit [Ping timeout: 260 seconds]
wcohen has quit [Ping timeout: 250 seconds]
brolley has left #systemtap [#systemtap]
mbenitez has quit [Quit: Leaving]
bchrisman has quit [Quit: Leaving.]
<jistone> aside, I'm thinking of generating 'bool is_foo()' and 'bool is_foo(foo*& ret)' for all expression subtypes
<fche> hm, dynamic_cast<> not good 'nuff?
<jistone> I could -- thought you weren't a fan of dynamic_cast?
<fche> true
<fche> I'm a fan of none of those really tbh; it indicates a design weakness
<jistone> as in, you think downcasting should never be needed?
<fche> as little as possible
<fche> this might be on this side of that rather than that side, but think about it
<fche> cxx_override ?
<jistone> ... not sure what your sides are here...
<fche> a fuzzy way of saying that this case may be right on the edge, so needs more thinking to know which side
<fche> I love the code simplification involved in your patch though
<jistone> cxx_override is a #define I added during the earlier c_tmpcounter changes. it's just "override" for compilers that are c++11 enough
<jistone> (and nothing otherwise)
<fche> will need to look up what that means
<jistone> it means this declaration *must* override something from its base classes
<fche> aha cute.
<jistone> creates an error if it doesn't, like if you made a typo in the signature
<fche> anyway the code lgtm overall
<jistone> (there's also "final" which prevents further overrides)
<fche> let's hold back on is_FOOBAR till a case-by-case basis use appears
cbzx has quit [Quit: Konversation terminated!]
<jistone> should I leave these is_literals? or make those calls just dynamic_casts?
<jistone> they're only in a couple call sites
<jistone> btw, I also noticed: struct expression_is_functioncall : public expression_visitor
<jistone> which is a long way around for a similar goal
* jistone intends to nuke that
<fche> yeah, visitors are the other ooish design pattern for this sort of thing
<fche> not sure about that one.
<fche> but anyway
<fche> back to your patch
<fche> is is_literal_number() and is_literal_string() anywhere not used in || expression? (except for c_unparser::c_assign) ?
<fche> ie. can we make do with a is_literal()
<jistone> (at worst, expression_visitor is going to dig completely through all sub-expressions, when really that use only cares about depth=1)
<fche> could make a non-deeply-traversing visitor class easily enough
<jistone> those is_literal are only used in c_expression and c_assign at the moment, nowhere else
<jistone> it's just a simple vtable call
<jistone> (which visitor patterns also have to do)
<fche> re. c_unparser::c_assign, can we ever have gone that far (with type checking etc.) and not have pe_long && is_literal_number || pe_string && is_literal_string?
<fche> ie. is e->type checking completely moot here?
<jistone> that's my paranoia, I guess
<fche> assert your paranoia sir :)
<fche> hm.
<fche> so if we only have one and a half consumers of is_FOOBAR ...
<jistone> and actually, now c_expression is only used by that c_assign, so I could fold it in and be sure of literalness
<fche> how about a dynamic_cast over in ::c_assign ?
<jistone> ok. do you care if I kill c_expression too, fold it in?
<fche> go for it
* jistone will come back for round two...
* fche will walk the ring with the giant 2 sign