IRC Log Viewer » #firebreath » 2011-06-29

IRC Nick Time (GMT-7) Message
jtojanen 05:06 Kalev: Okey, so it might be a copy-paste issue in ScriptingCore precompiled_headers.h lines 6 and 9 ?
It seems that ScriptingCore needs Boost.Regex as it includes boost/asio.hpp in URI.cpp line 24, and ScriptingCore is common for all platforms/projects
kalev 05:06 jtojanen: oh, yes, indeed.
I have no idea what to make of precompiled_headers.h; better to ask taxilian_away about it
but I'm using external boost on Linux, and ScriptingCore has never dragged in boost_regex for me
could it be that you only need to link to boost_regex if you use certain functions from boost::asio? And that URI.cpp uses only a subset of boost::asio that does not need boost::regex?
jtojanen 05:06 The deep problem lies in BOOST_ALL_NO_LIB. Boost/asio.hpp includes boost/asio/read_until.hpp which in turn includes boost/asio/detail/regex_fwd.hpp which includes boost.regex which in windows (MSVC) environment uses Boost auto-linking feature if BOOST_ALL_NO_LIB is not defined.
BOOST_ALL_NO_LIB is used if WITH_SYSTEM_BOOST is not defined, see buildconfig.cmake line 19
You are right that URI.cpp uses only a subset, but problem comes from auto-linking feature. One solution would be add #define BOOST_REGEX_NO_LIB in precompiled.h
jtojanen 05:06 Kalev: I will ask Taxilian if we can fix this by changing buildconfig.cmake to always define BOOST_ALL_NO_LIB, which disable auto-linking feature
kalev 05:06 good idea
jtojanen: if you say that it's using auto-linking, why isn't auto-linking doing its job and linking with boost_regex?
I'd suspect there's something else going on. Do you use static boost libraries?
my working theory is this: including boost/asio.hpp with auto-linking enabled causes firebreath to link with static boost_asio. Now, boost_asio.lib in turn uses symbols from boost_regex.
If you used boost DLLs, everything would work: firebreath would get linked with boost_asio.dll, which in turn is linked with boost_regex.dll
however, if you use static libraries, firebreath only gets linked against the static boost_asio, and no more.
taxilian 08:06 jtojanen: I'm here; reading back through the logs
jtojanen: yeah, so we don't actually need boost regex, but when using system boost it seems that it tries to pull it in
I'm not sure what to do about that
jtojanen: also, is there anything in your firebreath branch (which I notice has diverged a fair bit) that I should pull into trunk?
neilg_ 08:06 You can tell boost not to automatically link
And then that works. Anybody who uses boost will need to link against the libraries but that has to be done for all non-Windows platforms anyway
taxilian 08:06 hmm. that might be a better way to do it; kalev, you around to weigh in?
cmake will already manage the linking anyway
it doesn't need the autolink even when WITH_SYSTEM_BOOST is enabled
neilg_ 08:06 Exactly
I had this problem before and mentioned it, it's a new issue with a recent change in FB - I'd never seen the issue before. But defining BOOST_ALL_NO_LIB solved my issues!
taxilian 08:06 in fact, that would solve an issue with firebreath boost also
neilg_ 08:06 Right - no modified boost headers ;)
taxilian 08:06 exactly
particularly since I need to update to the latest boost
it's been awhile
kalev 08:06 Yes, I agree
firebreath already has to manually link with boost libs because of other platforms, so losing the auto-link on Windows is no big deal
neilg_ 08:06 And that's definitely my opinion too :)
And since I agreed with my own opinion - that means I get two votes... right? ;)
taxilian 08:06 neilg_: of course ;-)
kalev 08:06 no, you get three: jtojanen also suggested that earlier :)
14:41 < jtojanen> Kalev: I will ask Taxilian if we can fix this by changing buildconfig.cmake to always define BOOST_ALL_NO_LIB, which disable auto-linking feature
taxilian 08:06 heh. so for some reason I lost part of the conversation last night
there must have been a netsplit
I feel out of the loop ;-)
neilg_ 08:06 I win, I suggested this weeks ago! Yay! ;)
taxilian 08:06 now the only problem is that I can't do this today because I'm on a contract
kalev 08:06 and I don't use external boost on Windows, so I couldn't really test it
taxilian 08:06 and tomorrow through Saturday I'm out of town, away from computers, and probably have no cell phone access
(family reunion)
neilg_ 08:06 Damnit kalev, you win. You mentioned it last year! ;)
kalev 08:06 oh, is that so?
neilg_ 08:06 Yup - 2010/09/14 11:38:36<kalev>BOOST_ALL_NO_LIB=1
At least I got 2 votes. I won something! lol
I have the change locally, I'll commit it
taxilian 08:06 neilg_: could you please create a jira ticket as well?
this would be good to track for the changelog
neilg_ 08:06 No problem!
jtojanen 08:06 I am back, and vote for this change :)
taxilian 08:06 thanks, neil
hehe. awesome
jtojanen: you got a few minutes to ask about something else?
jtojanen 08:06 sure..
Don't take anything from my fork, won't work for you
taxilian 08:06 yeah, I was seeing that
so IE9 addEventListener doesn't work for us
fails silently
dougma and I found that there are some new interfaces, we were trying to figure out if we could use them to add an alternate method for firing events in IE9 that would work with addEventListener
jtojanen 08:06 Since when?
taxilian 08:06 since IE9
try it
attachEvent works
addEventListener does not
possibly only when a certain doctype is set (FIREBREATH-11, I think, refers to that doctype)
FireBreathBot 09:06 FIREBREATH-11: Summary: Using a DOCTYPE definition in the HTML page breaks IE 9
FIREBREATH-11: Assigned To: richard
FIREBREATH-11: Priority: Major, Status: Closed,
jtojanen 09:06 I have been using attachEvent, but never addEventListener
taxilian 09:06 right; it's new in IE9
also attachEvent with that doctype set sometimes doesn't work for certain event names; FIREBREATH-93
FireBreathBot 09:06 FIREBREATH-93: Summary: IE9 suppresses certain events when a DOCTYPE is present
FIREBREATH-93: Assigned To: richard
FIREBREATH-93: Priority: Major, Status: Open,
jtojanen 09:06 IE9 fixed a lot of things, but seems that it broke as many
taxilian 09:06 more reference:
anyway, my theory is that it didn't really "break" it so much as that it changed the way it works
for example, take a look at (IHtmlElement5)
it has onabort, onsubmit, onload, oninput, etc
also see
I'm thinking that perhaps we can query our html element (that you showed us how to get) for a IEventTarget interface and try calling dispatchEvent
jtojanen 09:06 I seems that onabort is a property, as it has get/put methods; I think we need to parse the typelib, and use these through IDispatch
taxilian 09:06 that would probably help with the problem of attachEvent losing some event handlers, but what about addEventListener?
do you think the IEventTarget approach is feasible/valid?
jtojanen 09:06 FIREBREATH-93 issue comes from the fact that IDispatch reserved DispatchIDs (dispid) for names; IE caches those names to dispid
FireBreathBot 09:06 FIREBREATH-93: Summary: IE9 suppresses certain events when a DOCTYPE is present
FIREBREATH-93: Assigned To: richard
FIREBREATH-93: Priority: Major, Status: Open,
taxilian 09:06 ahh... yeah, that makes sense
we could just add those dispids to axutil.cpp
!findfile axutil.cpp
FireBreathBot 09:06 Found 1 matching file(s) in the master branch. First 1 are:
taxilian 09:06 still wish I knew what securityctx is; DISPID_SECURITYCTX. we get it all the time from IE
jtojanen 09:06 IE9 SDK probably contains those ids
taxilian 09:06 hmm. I am not going to be able to tackle this for at least 2 weeks :-/
I didn't even consider the dispid problem, though
jtojanen 09:06 taxilian: I have created another fork under linkotec. I try to keep it clean so you can pull staff into master without side affects.
taxilian 09:06 cool =] thanks
jtojanen 09:06 I will revert the change CMakeLists.txt and apply the winning solution to buildconfig.cmake :)
taxilian 09:06 neilg_ may have been working on that
jtojanen: I do want to get your better unique id hashign thing, though
jtojanen 09:06 Sure that idea comes from TR-1 hash
neilg_ 09:06 Yep, I've had that change since the start of June - just need to push it
taxilian 09:06 awesome. jtojanen: I'll just cherry-pick the hash
neilg_: do you have commit rights to the repo?
FireBreathBot 09:06 Commit 378b4aa on master by Richard Bateman: "FIREBREATH-108: Added missing using namespace"
neilg_ 09:06 I'm not sure actually. I was going to say yes - but I've only ever submitted patches
FireBreathBot 09:06 Commit ca26b92 on master by Jukka Ojanen: "Better way to get a unique key for this plugin instance"
taxilian 09:06 that's fine; that works, just let me know
after applying that I need to get back to work, though
glad to see jtojanen and kalev, though; don't see you guys much anymore =]
FireBreathBot 09:06 JIRA issue issue commented by richard "I just pushed a fix, I hope, but I haven't been able to test it; could you let me know if that wo..."
kalev 09:06 taxilian: likewise, glad to see you too.
FireBreathBot 10:06 JIRA issue issue created by neilg
FireBreathBot 11:06 Commit 67edcc0 on master by Richard Bateman: "FIREBREATH-109: Turn off boost autolinking on windows"
FireBreathBot 13:06 Commit 84d602e on master by Richard Bateman: "FIREBREATH-108: Fixed typo breaking build for HttpService"
JIRA issue issue resolved by richard "There was a typo; this is confirmed to work for me, anyway, on windows."
FireBreathBot 13:06 Commit 0fdbec8 on master by Richard Bateman: "Fixed possible crash w/ converting from VariantList/VariantM..."
FireBreathBot 15:06 Commit 52c1205 on master by Richard Bateman: "Fixed minor bug in UploadQueue field naming"
Skype 17:06 FireBreath is awesome!!! my plugin just works without any changes on IE 8,9 (7/8/9 also tested in F12 compatibility mode), Firefox 5, Chrome, Safari 5.0.5, Opera 11.50, running Windows 7 64bit
Ok now only if I can get this working on Firefox 3.6.18 (still supported by Mozilla) I'll be sussed
Skype 21:06 Ok found the problem with Firefox 3.6.18 not being able to load the plugin using Process Monitor from M$. If the Registry Value HKCU/*/MozillaPlugins/*/Path value is too long then Firefox cannot find the plugin and Process Monitor shows BUFFER OVERFLOW. So I changed the path to C:\npUploadControl.dll where I stored my plugin then it worked fine. Note Firefox 5 does not have this problem.
dougma 21:06 weird
Skype 21:06 Yeah I guess that path needs to be short
dougma 21:06 can't say i've actually tested under ff versions < 4
Skype 21:06 The Mozilla guys might have fixed this for Firefox 4+, I wish I had the luxury of supporting Firefox 4+ but we are trying to supporting Firefox 3.6 +
dougma 21:06 by the time i get my plugin out ff will be at 6 or 7. :/
Amir_ 21:06 Hi
dougma 21:06 hi
Guest71414 21:06 I am trying to create a project on windows
and I get this error 'cmake' is not recognized as an internal or external command,
dougma 21:06 install cmake
Guest71414 21:06 i couldn't find any cmake executables
any idea what i should do
dougma 21:06 dougma> install cmake
Guest71414 21:06 i see, so cmake is a separate project
dougma 21:06 read this:
Guest71414 21:06 thanks alot
dougma 21:06 ok
Skype 21:06 Go here
Guest71414 21:06 thanks mate
Skype 21:06 And you python 2.7.2, I tried 3.2 but that didn't work
s/you python/you need python
Guest71414 21:06 I did that
cheers guys
Skype 22:06 plugin().valid is this a c++ defined property or javascript?
Hrishikesh 23:06 how can i distribute the plugin so that use dont have to install it manually
FireBreathBot 23:06 Hrishikesh: 14 Jun 15:26Z <taxilian> tell Hrishikesh there is a bug in latest Chrome, FF4, and Safari that make exception messages get lost. Nothing we can do about it, I'm afraid
dougma 23:06 does this help:
Hrishikesh 23:06 dougma: thanks
dougma: i am using msi installer
is it good method?
dougma 23:06 i think so
Hrishikesh 23:06 yes i think its best among all the methods
i am detecting the plugin from js and showing notification to download the ms