IRC Log Viewer » #firebreath » 2013-06-18

IRC Nick Time (GMT-7) Message
diorcety 04:06 hi
It can be usefull to add a macro in order to add #define in config.h
taxilian 07:06 diorcety: you can override the template used to create config.h if you want
just copy config.h from gen_templates into the root of your plugin project
diorcety 08:06 indeed :)
tonikitoo 09:06 hi there.
if I am passing from JS an Array object, and taking it as JSObjectPtr. Should not we be able to cast it to std::vector
?
taxilian 09:06 you can't cast it
you can probably convert_cast it
but keep in mind that when you pass something in and use it as a vector it's actually copying everything
it isn't actually a vector behind the scenes, it's a js object
tonikitoo 09:06 ah!
tonikitoo| 10:06 taxilian, ok. So in http://www.firebreath.org/display/documentation/class+FB+variant+convert_cast where the convert_cast is explained, there is an item that states that a JSObjectPtr can be converted to a an container stl class, i.e. a vector in this case
was it talking about a copy of the values as well?
s/a an/a/g
taxilian 10:06 yes
tonikitoo| 10:06 alright
taxilian 10:06 convert_cast works by copying the underlying type to the type specified unless the types are exactly the same
i.e. string to a number, number to string, js array to stl class, js object to stl dict type, etc
tonikitoo| 10:06 I take that for example, Array(1, 2, 3) and std::vector<float> do not fit to "unless the types are exactly the same" category
taxilian 10:06 not even remotely close
one is a javascript object of type Array
the other is a stl std::vector
the js object is a NPObject* in C++
any time you want to get data from it you have to ask the browser
when I say exactly the same I mean they have to be exactly the same
std::list<float> and std::vector<float> are pretty similar, but they aren't exaclty the same
JSObjectPtr and std::vector<any type> aren't even remotely close
tonikitoo| 10:06 taxilian, got it. thanks for explaining
taxilian 10:06 np
CSGuy 11:06 So I'm having a problem where JSObjectPtrs appear to be spontaneously becoming null
I pass a reference to a JS function into my firebreath plugin
and i have some code that checks the refference
if(reference) { do stuff}
but the program is getting an access violation on 'if(reference)'
it appears that 'reference' has become a dangling pointer, and I'm not sure why that would happen
taxilian 11:06 I don't believe that should be possible
CSGuy 11:06 Yeah I'm pretty befuddled about the whole thing. Just to double check I'm no doing anything stupid, I'm using a JSObjectPtr which I initialize during plug in start up
void SpeechBrowserAPI::jsInit(const FB::JSObjectPtr& loggingCallback, const FB::JSObjectPtr& evalCallback) { jsLogCallback = loggingCallback; jsEvalCallback = evalCallback;
}
nothing wrong with that ^^ is there?
the actual line of code that is crashing the program is:
return px == 0? 0: &this_type::px;
from 'operator_bool.hpp' in boost
taxilian 11:06 what browser?
CSGuy 11:06 firefox & chrome both do it
ff version 21
taxilian 11:06 may want to attach a debugger and step back through the stack
CSGuy 11:06 thats how i found its crashign at 'opator_bool.hpp'
i'm using VS2010
and the JSObjectPtr
taxilian 11:06 pastebin the full stack?
CSGuy 11:06 how do i do that/
?
nvm ill google it 1 sec
http://pastebin.com/raw.php?i=b2hp8fNW
and here is the pastebin for my log functino
http://pastebin.com/Fn2yupSv
taxilian 11:06 hmm
I do not know why that would happen
CSGuy 11:06 yea :S
i'm thinking i might be a bug in boost? or maybe I'm not using the shared_ptr correctly
taxilian 11:06 my first instinct is that ti's related to the threading you're doing
CSGuy 11:06 oh that might be it
i do call into a new thread cuz the plug in does some heavy lifting speech recognition
i'll go look at that, thanks for the suggestion
taxilian 11:06 main thing would be if there is some kind of race condition with initially setting it
the object itself is threadsafe, but creation and destruction is not
CSGuy 12:06 Awesome, I think I fixed the bug, thanks taxilian, you were right that it was a threading issue