IRC Log Viewer » #firebreath » 2011-05-25

IRC Nick Time (GMT-7) Message
_pq_ 06:05 hello
FireBreathBot 06:05 _pq_: 14 Apr 16:02Z <taxilian> tell _pq_ in 1.5, you need to set FBMAC_USE_INVALIDATINGCOREANIMATION to 1
_pq_ 06:05 should check logs to understand meaning of that ;P
_pq_ 06:05 new issue:
anyone has experienced using xcode4 to build firebreath on macos?
linearray 06:05 yes
I experienced that
and went back to xcode3
_pq_ 06:05 oh
like, indexing boost = big fail?
linearray 06:05 indeed!
_pq_ 06:05 shit
is there any way to avoid indexing that?
linearray 06:05 nope
the internet says indexing can't be turned off
_pq_ 06:05 yep
i'll do a command line build
linearray 06:05 the second problem I had with xcode4 was that prepmac would add build targets instead of replacing them, if xcode is open
so after a while I had 50 targets
_pq_ 06:05 cool
well, i can afford to close xcode to run prepmac
linearray 06:05 well
when you load the new project file, doesn't it index everything again? :)
_pq_ 06:05 no
linearray 06:05 ok
_pq_ 06:05 there's a cache at /Library/Cache or so
but the problem is not the time it requires for indexing
is the RAM it requires to keep index in memor
memory
linearray 06:05 hehe, I actually took the occasion to buy more RAM
didn't try xcode4 yet though
_pq_ 06:05 i guess indexing is still inefficient with boost and intensive metaprogramming
linearray 06:05 ha, xcode will peak at 6.8 GB
so yeah, with 16 GB RAM you will be fine :)
_pq_ 06:05 i don't have 6.8 GB free hard disk space
linearray 06:05 when I tried indexing with 8 GB RAM it took like 40 minutes
due to swapping
and for me this cachine did not work; it would index over and over again
caching*
_pq_ 07:05 next time will take not so much time
the problem is that every time you modify some file (e.g. you press a button) it has to be re-indexed
and if it includes some boost it will probably include most boost, and it will probably index that
i managed to build once an empty plugin
then i had to reboot
linearray 07:05 hm, even with lots of ram indexing still takes several minutes
_pq_ 07:05 yeah but it's just the first time you run it
linearray 07:05 ok, I will try
_pq_ 07:05 also, don't try putting your source code in an NTFS filesystem
linearray 07:05 didn't want to yet
_pq_ 07:05 no, no "yet"
don't even think about it
linearray 07:05 :)
_pq_ 07:05 just opening the project will take more time than building the whole thing in a good filesystem
don't know whose fault it is
linearray 07:05 what driver do you use? afaik os x can only read ntfs
_pq_ 07:05 ntfs3g
google for it
it mostly works except for compiling
linearray 07:05 i see
_pq_ 07:05 however if the LCD display says "indexing" it could already have finished that
linearray 07:05 it's still using two cores
_pq_ 07:05 well, it hasn't then
a 16gb mac is probably out of budget for most NASA projects
linearray 07:05 oh well, RAM is cheap these days
I paid 120 euros or so
_pq_ 07:05 not if you buy at mac store
but it's probably cooler than standard ram
linearray 07:05 blessed by steve himself
_pq_ 07:05 try "man xcodebuild"
you can build from command line
really faster
linearray 07:05 I just tried loading the project, recreating the build directory and loading the project again
_pq_ 07:05 how do I test the newly created plugin?
linearray 07:05 it really IS indexing everything again
_pq_ 07:05 yeh if you delete it i wouldn't expect otherwise
linearray 07:05 ok :)
what do you mean, test?
_pq_ 07:05 want to see it in firefox
linearray 07:05 I think putting it into ~/Library/Internet Plugins
should work
symlinking rather
_pq_ 07:05 yeh unix doesn't have the windoz problem "if you have opened it you can't modify it"
taxilian 09:05 _pq_: you can also use cmake to build from the command line... cmake --build <build dir>
it will launch xcodebuild for you, but also works cross-platform. great for build scripts
neilg_ 09:05 Yep, putting the plugin (whether through symlinks or not) in /Library/Internet Plugins or ~/Library/Internet Plugins will work for you
taxilian 11:05 anyone see a problem with releasing 1.5.2?
neilg_ 11:05 Nope
kalev 13:05 taxilian: yay, CMake 2.8.5-rc1 was released with your Mac CFBundle fix
taxilian 13:05 ooohhh… =]
finally
FireBreathBot 14:05 JIRA issue http://jira.firebreath.org/browse/FIREBREATH-81 issue created by donaldlsmithjr
JIRA issue http://jira.firebreath.org/browse/FIREBREATH-81 issue commented by richard "what that means is that FireBreath *declines* to set any values for those things; if parentNode a..."
FireBreathBot 14:05 JIRA issue http://jira.firebreath.org/browse/FIREBREATH-81 issue commented by donaldlsmithjr "I apologize for filing an issue on this, I had meant to ask in the forum. We have added the addi..."
neilg_ 14:05 What was the CFBundle fix?
taxilian 14:05 it's the fix that allows CMake to generate a plugin bundle natively
no longer requires that you use the python script to patch the xcode project
neilg_ 14:05 Oh, cool. I'll be wanting that then!
FireBreathBot 16:05 JIRA issue http://jira.firebreath.org/browse/FIREBREATH-71 issue resolved by richard
JIRA issue http://jira.firebreath.org/browse/FIREBREATH-81 issue resolved by richard "No worries; this really should be fixed. FIREBREATH-5 actually will address this issue... I just ..."
dougma 19:05 hi... re: JSObject::getJSAPI what is the 'associated jsapi' that it is getting?
i'm confused, because JSObject is a JSAPI
or is it sometimes a proxy?
taxilian 20:05 dougma: still here?
JSObject is a JSAPI
dougma 20:05 hi
taxilian 20:05 but sometimes a JSObject wraps an IDispatch*
which is actually a COMJavascriptObject
whcih wraps a JSAPI...
so getJSAPI will get that JSAPI
if there is one
so in other words, if you return a JSAPI object to the page, and it gets passed back in, getJSAPI can be used to get the underlying JSAPI object rather than the wrapper for the IDispatch*
JSAPIAuto's auto conversion tools will do all that for you, btw
or convert_cast
dougma 20:05 ah...
cool
so i don't have to go probing getJSAPI
taxilian 20:05 not usually
it's pretty rare that you'll need to access an IDispatchAPI object directly, actually
usually you should be good just using a FB::JSObjectPtr
dougma 20:05 i am passing the dom object element into my control and trying to get to it's jsapi
which is proving difficult
taxilian 20:05 DOM objects are trickier
because the IDispatch* you get is actually a proxy
dougma 20:05 in activex, you can just queryinterface :)
taxilian 20:05 which means you can't actually get the original in any meaningful way that I know of
sure you can.. but you don't get the same object
dougma 20:05 if IE is proxying my object onto the dom element and I QI it can actually give me the interface... but that's v-table interfaces for you. :)
taxilian 20:05 yeah, it'll give you the interface
dougma 20:05 IE also has an "object" member on the dom object element which helps things
taxilian 20:05 similarly you should be able to get the IDispatch* interface and call methods using Invoke, GetProperty, SetProperty and it *should* go thorugh the proxy to the underlying JSAPI object
but since it isn't literlaly
dougma 20:05 right.
taxilian 20:05 isn't literally the same object it's tricky (not always possible?) to get the actual JSAPI object
however, I think that can generally (always?) be designed around
dougma 20:05 sure. now i haev a new problem. :)
i am attaching an anonymous function to onload
and it's not being called; whereas a non-anonymous func is fine
seen that before?
currently debugging it anyway
taxilian 20:05 you mean in the param tag?
dougma 20:05 i've attached it via control.onload and <object onload=>, but not tried param
taxilian 20:05 I'm shocked that either of those work
ever
dougma 20:05 oh!
i should param then? :)
taxilian 20:05 yes, that would probably be a good idea =]
so the problem with control.onload is that it has to be loaded before the event can attach...
and it's not safe to have the plugin execute arbitrary javascript that it finds in an attribute or param tag
so… you're left with global javascript functions
dougma 20:05 setReady doesn't happen until i stick it in the dom....
so i can get to .onload
taxilian 20:05 okay, now I'm *really* shocked that anything is working
dougma 20:05 ha!
creative creation methods :)
taxilian 20:05 when you stick it in the DOM InPlaceDeactivate is called; when that happens, any event handlers that are attached are discarded
were it not so, the plugin would never shut down cleanly
however, it used to crash, and then it invalidated the whole plugin, so just invalidating all held IDispatch* references is a step in the right direction =]
dougma 20:05 well... i am not fully up on trunk maybe we're talking at cross purposes. :?
taxilian 20:05 generally speaking if you want consistency and reliability, never create the object tag with a mimetype out of the DOM
either put the whole thing into the dom with an innerHTML (not query .html()) set or put it in and then set the mimetype
probably the order you're using just happens to accidently work most of the time
is more my guess
dougma 20:05 i see...
taxilian 20:05 I would love to fix that, but I can't figure out how
dougma 20:05 because we have a need to create hundreds of controls we experiment a lot with creation order to find the fastest way
taxilian 20:05 the fastest way is likely to be setting .innerHTML = "<object ….>….</object>"
definitely the most reliable way
dougma 20:05 ok
taxilian 20:05 I have a suspicion that if I were to alter it so that IDispatch* that are set using ConnectionPoints could probably be kept safely without affecting the lifecycle
because those are some sort of weird proxy object
they are actually asynchronous even when called synchronously
which is weird
but any other javascript object passed into the plugin (IDispatchAPI) if we don't release it during InPlaceDeactivate, Close() is never called and the FBControl object is never freed
it's really annoying
I have 6 books on COM and I have been unable to find anything really useful that might explain the issue
though I do have one untested theory
dougma 20:05 hmm... why is it not safe to have the plugin execute arbitrary javascript from the onload param?
taxilian 20:05 because javascript executed by the plugin is not always (I'm unclear on specifics) executed with the same permissions as the javascript from the page
in other words, cross-site javascript would probably work
cross-domain
so people could use your plugin to bypass browser security features
gotta go get pizza for my wife
bbl
dougma 20:05 ok...
dougma 22:05 but how is the security context for onload different to any other event or plugin-initiated callback?
taxilian 22:05 onload is not a real event
it's a string
and so the only two ways that a plugin can call it are 1. look up a function of that name or 2. eval the javascript
thus it has to be a named global function
because otherwise how do we get it?
dougma 22:05 ah right. i forgot it was just a string (because i'd been setting it as a property) :)
taxilian 22:05 as a property it doesn't matter, as long as it is a function object
but that will have inconsistent results across different browsers for the load event
all others should be okay
dougma 22:05 ok, thanks. :)