IRC Log Viewer » #firebreath » 2010-09-17

IRC Nick Time (GMT-7) Message
amackera 09:09 hay guys :)
kalev 09:09 hey :)
amackera 09:09 was there somebody involved with firebreath that is associated with selenium? i seem to remember something like that
kalev 09:09 that would be nirvdrum
nirvdrum 09:09 Yeah.
I'm on the Selenium core team.
amackera 09:09 oh hey cool :)
we just hired a co-op student who's working on a selenium thing for us
taxilian 09:09 so trunk now has the cheetah dependency removed
that should make it easier for new people to get going with fbgen
amackera 09:09 awesome!
taxilian 09:09 the funny thing is, Jarom is the one who said he was going to do it
but I cced his brother Ben
(Ben started the original, Jarom finished it)
Ben was bored this morning, I guess
'cause I added the issue last night
and he submitted a patch this morning...
kalev 09:09 haha, that's a good story
taxilian 09:09 I still would really like to get a web version built sometime
I have to tell you guys; one of the best feelings on an open source project is when someone else just suddenly submits a patch that fixes a problem you've been worried about
and you're like "oh, wow… I don't have to do that now"
taxilian 10:09 if you guys haven't done so, go mark the ohloh "I use this" on the firebreath page
amackera 11:09 weird i can't add myself as a contributor to the firebreath thing on ohloh
kalev 11:09 amackera: go to and click on the "I am this person" button
amackera 11:09 ahh thanks kalev
taxilian 11:09 hehe. thanks, kalev; I've been thinking of trying to get that filled out =]
kalev 11:09 I discovered ohloh for myself a few weeks ago and played a bit with it, so now I'm a pro when it comes to adding different projects to my name
taxilian 11:09 hehe
now you just need to set up a gravatar
kalev 12:09 yep
amackera 12:09 evidently chrome is on a 6 week release cycle now
taxilian 12:09 btw, 362 hits to the project page yesterday
last thursday was 102 hits
amackera 12:09 nice!
taxilian 12:09 190 on wed
last wed 92
on colonelpanic, ~400 hits both days
~95 the week before
so not too bad
kalev 12:09 if we get one new contributor out of that, it was well worth doing all that advertising
taxilian 12:09 and if you search twitter for FireBreath you'll find there were several tweets
that's my thoughts as well
and getting a link on the mozilla page should be huge
kalev 12:09 yeah, that's probably worth much much more than all the blogs and tweets together
taxilian 12:09 glad I thought of it, then ;-)
I'm trying to get it on as well
it'll be interesting to watch what the traffic does over the next week to month
that'll tell us how useful it was (well, one indicator anyway)
taxilian 12:09 momentum hasn't died off yet either; we're already at 97 hits today on the project site, which is about an average day
and it's pretty early still
amackera 12:09 taxilian: i like the things you've added to the main page on gcode
although the ohloh thing doesn't seem to be updating
taxilian 12:09 hmm
maybe shift-reload?
I'm going to look into maybe using a linked repo for the boost stuff so that it doesn't show up in our ohloh stats
that will make them actually useful
amackera 12:09 ohlh also says we don't have a lot of comments in our source code
taxilian 12:09 probably because most of the lines of source code are boost
amackera 12:09 ahh yeah that makes sense
cygmatic 12:09 comments? who needs comments anyway? *cough
amackera 12:09 we are *so* good at programming, our code is like self-documenting
cygmatic 12:09 hm, i thought it didn't need documentation as its perfect anyway? ;)
taxilian 12:09 hehe
well, I gotta run. class in 30 minutes, need to eat first
feel free to continue to make improvements to the home page; I'm not certain I like it fully, but I was fiddling while I waited for my mac to reinstall (tried to install the beta update that goes with ios 4.2; it went badly)
be back later
cygmatic 15:09 Looking at the bottom of i wonder... where is that R code coming from? *g
taxilian 15:09 lol
probably boost
this page is why I want to find a way to remove it from the codebase
so cygmatic, I have a thought
when I did the variant conversion stuff, I didn't know about boost::lexical_cast
we already have it in there
think we could find a way to remove most of that code to just do a lexical_cast?
it could potentially catch a lot of cases that we don't know how to handle
cygmatic 15:09 well, the fun part with boost::any/FB::variant is that its type is erased
taxilian 15:09 right
that's the part I haven't found a way around yet =]
but, there might be a way...
it creates a type specific template struct, right?
what if we made a lexical_cast call on that struct?
cygmatic 15:09 hm, what struct are you referring to?
taxilian 15:09 struct fnxs
cygmatic 15:09 in general lexical_cast is great if you have two static types and want to convert from one to the other
taxilian 15:09 variant.h line 101
cygmatic 15:09 but here there is one static type (the target type) and one dynamic type (the source type)
taxilian 15:09 I'm sure it's better than the stringstream stuff I'm using
but with templates, the function itself could deal with two static types, right?
I think this could actually work
cygmatic 15:09 maybe i'm misunderstanding what you are referring to
taxilian 15:09 maybe I'm delusional
you never know :-P
cygmatic 15:09 :D
are you talking about cast<> et al?
taxilian 15:09 well, yes and no
I'm wanting to make this be the basic implementation of convert_cast
cygmatic 15:09 fnxs uses one static type which is the type the variant is created from
taxilian 15:09 so the fxn_ptr_table has some functions in it that actually know what the type is, right?
so could that be tweaked to add a template function for converting to a destination type?
then again, that probably can't work
since templates have to be generated at build time
cygmatic 15:09 yes, but it generates some actual functions at compile time which are later used at runtime
taxilian 15:09 right
yeah,guess that won't work
cygmatic 15:09 the problem is coming from that point to the point of use - on that way the static type is lost
taxilian 15:09 ahh, well, I can still use it instead of some of the messy current stuff
cygmatic 15:09 and some walking-through-a-finite-type-list has to be done
you mean replacing the CONVERT_ENTRY_XXX?
taxilian 15:09 the contents thereof, anyway
cygmatic 15:09 that should work nicely :)
taxilian 15:09 instead of using stringstream
you can do boost::lexical_cast<std::string>(number), right?
cygmatic 15:09 yes
lexical_cast does more or less the same
just nicely encapsulated
taxilian 15:09 right
and less potential bugs in our code
cygmatic 15:09 maybe actually using boost::variant instead of any would have been nicer
with boost::variant visitors can be applied which eases some things
taxilian 15:09 yeah, there were some other concerns with boost::variant, though
and I'm not sure if we could have applied the conversion stuff we use on it
cygmatic 15:09 i think there would have been no problem
taxilian 15:09 could be
cygmatic 15:09 the only limitation i can think of is that you can't simply put everything in it
taxilian 15:09 what can you put in it?
cygmatic 15:09 only everything specified in the type-list (boost::variant<A, B, C, ...>)
taxilian 15:09 ahh
well, given that what we have is working great
and we don't know of any performance or stability reasons to change
I say we stick with what we have =]
I do like the flexibility that this one gives us
cygmatic 15:09 yeah, just fantasizing about the ideal clean code ;)
taxilian 15:09 lol
I wouldn't say that FireBreath is bad, particularly compared to most projects
but then, I admit to some bias in the matter
cygmatic 15:09 from personal cleaning-up-messes-all-over-the-place experience i definitely agree
taxilian 15:09 hmm. boost::lexical_cast doesn't convert double to long
cygmatic 15:09 thats what numeric_cast is supposed to cover
taxilian 15:09 now you tell me =]
cygmatic 15:09 hearing lexical_cast i assumed you were talking about the string<->number conversions ^^
taxilian 15:09 oh, I was
but I figured it would work for all of 'em
using numeric_cast would fix our problem with not being able to allow a normal int...
since it would throw an exception
cygmatic 15:09 i thought i already caught these at compile time?
taxilian 15:09 you did
but we could optionally allow them and numeric_cast would throw an exception in the case that it would be a problem
anyway, either way I'm going to put it in
it will at least catch signed/unsigned conversions
the cost is relatively low
cygmatic 16:09 hm, i don't know, using that to fix the int problem could develop into a hidden pitfall
taxilian 16:09 might be
I say leave it as it is for now
but I will put the numeric_cast in
since it could potentially catch a hidden pitfall
cygmatic 16:09 on the other hand... not catching exceptions for cast<>() is dangerous anyway
sounds good :)
taxilian 16:09 huh
'xept it doesn't seem to be here
there is a numeric_cast, but it doesn't match what the docs I'm reading say
wants two template params, for example
can't get it working. ahh, well, maybe later
cygmatic 16:09 but you only have to give it one as in "numeric_cast<TargetType>(fromNumber)"
taxilian 16:09 it did not work
and lexical_cast broke all the unit tests for converting decimal to int
to string
because it made 23.23 23.229999999
so I finally just put everything back
maybe I'll try again sometime =]
but it works, so why fix it?
cygmatic 16:09 right
boost/numeric/conversion/cast.hpp is not in FBs repository
taxilian 17:09 ahh
that explains it
taxilian 17:09 cygmatic: you around?
kalev: you around?
when you can, do a hg clone firebreath-dev
tell me what you think, (if you can even tell what I want you to tell me what you think about :-P)
cygmatic 17:09 i'm thinking i'm confused - does that help?
taxilian 17:09 lol
try it out
tell me if you notice anything different
aside from the fact that I created a new repo for dev
didn't realize I could do that before
cygmatic 17:09 ah, "pulling subrepo"... nice
taxilian 17:09 useable?
wow.. I just did a pull from a subrepo-enabled branch into an old branch
pretty much wasn't even noticeable; switched over perfectly
very nice
cygmatic 18:09 "adding file changes" is taking forever now... will try building fully when its done
taxilian 18:09 maybe I can find a way to make it forget those files? I bet that's the problem; all those files added, then removed
taxilian 18:09 well, I gotta run. Let me know what you think
that's kinda what I'm considering should be done with the examples and such as well
but just considering