IRC Log Viewer » #firebreath » 2014-07-14

IRC Nick Time (GMT-7) Message
chardy 11:07 Hi, I'm having trouble logging into the Issue tracker. Also, when I try to reset my password I get this message: "The password could not be changed by the credentials provider. org.apache.commons.httpclient.ConnectTimeoutException: The host did not accept the connection within timeout of 5000 ms"
Hi, I'm having trouble logging into the Issue tracker. Also, when I try to reset my password I get this message: "The password could not be changed by the credentials provider. org.apache.commons.httpclient.ConnectTimeoutException: The host did not accept the connection within timeout of 5000 ms"
taxilian 13:07 chardy: I'll have to look at it
chardy 14:07 thanks taxilian
taxilian 15:07 chardy: everything is working fine for me...
chardy 15:07 ah- it's working now
ah- it's working now
taxilian 15:07 idd
odd
odd
nothing about the server has changed
nothing about the server has changed
:-?
:-?
ahh, well, glad it's working
what's up? what are you filing?
chardy 15:07 I will enter an issue for the IE10 / threading problem we were discussing this morning on groups
taxilian 15:07 ahh
ahh
just FYI, I will not likely have time to address this myself in the near future; would you consider fixing it and submitting a pull request?
just FYI, I will not likely have time to address this myself in the near future; would you consider fixing it and submitting a pull request?
chardy 15:07 yes, no problem
taxilian 15:07 awesome =]
chardy it might be easiest to just throw a mutex into that function
into getComVariantBuilderMap specifically
the main reason for doing that rather than using a file scope is that none of this is used except on ActiveX, so it seems silly to initialize it when not even loaded by activex
chardy 15:07 that seems a bit heavy duty to me tho, just for a singleton accessor
RobW 15:07 To use the Firebreath library at our company. Other than providing the copyright and disclaimer associated with the new BSD license are there any other guidelines that must be followed?
taxilian 15:07 I definitely see your point on that, but on the other hand it will only really happen once that it matters
RobW: nope
chardy 15:07 I was thinking of putting this at the top of the ComVariantUtil file:
RobW 15:07 Great thank you!
chardy 15:07 ahh.. one sec where is a good place to copy code?
ahh.. one sec where is a good place to copy code?
(snippets)
taxilian 15:07 chardy gist.github.com is one of my favorates =]
s/favorate/favorite
RobW: As a point of policy, helping with tracking down issues would be appreciated and will tend to gain you quite a bit of goodwill should you ever need my help =]
RobW: As a point of policy, helping with tracking down issues would be appreciated and will tend to gain you quite a bit of goodwill should you ever need my help =]
but there are no stringent use restrictions
but there are no stringent use restrictions
chardy 15:07 https://gist.github.com/chrishardy99/a8f718931a763a5f8345
https://gist.github.com/chrishardy99/a8f718931a763a5f8345
RobW 15:07 :) well noted
:) well noted
taxilian 15:07 chardy: so, you're concerned about adding a single mutex around a function that runs once every time you load it in an activex browser; from my perspective, with this you have added something that will now get called every time you load it in *any* browser. The mutex seems less expensive to me
chardy 15:07 Isn't this IE-only code?
taxilian 15:07 it is, but since all the code is compiled into the same .dll file, all global code will be executed as soon as the module is loaded
I don't believe that boost::mutex is really all that expensive to use
chardy 15:07 oh right, duh. Blurred lines in my head for a minute between IE/Win and everything else.
taxilian 15:07 =] believe me, I understand.
chardy 15:07 Okay, I'll give it a shot and let you know when I have something
Cheers
chardy 16:07 @taxilian, to avoid using the mutex for every single access of that singleton (it is accessed frequently), we'd need some sort of double-checked locking. I'm not too experienced with this, except that it comes with a bunch of gotchas.
taxilian 16:07 I would personally file this under "premature optimization"
if you really think that it's going to introduce a heavy enough performance issue on startup to worry about, it would be better to find an early point in the activex initalization to call the initializer from
chardy 16:07 I'm guess I'm not that stressed about the performance, just wanted to do my due diligence.
I'm guess I'm not that stressed about the performance, just wanted to do my due diligence.