IRC Log Viewer » #firebreath » 2013-07-09

IRC Nick Time (GMT-7) Message
nopasa 02:07 @taxilian, thanks for your answer. But FB::SimpleStreamHelper::AsyncPost takes a parameter "const std::string& postData" ... it's string, not byte array. Do you still think it's ok to use it for sending binary files? It may be a dumb question as I didn't use C++ since school. And it was about 15 years ago :-/
diorcety 08:07 Hi
can i get object from one CorePlugin and set to another CorePlugin (from same library/factory) ?
taxilian 08:07 diorcety I don't understand your question
nopasa: you can't post binary data. you can get binary data from the server
diorcety 08:07 taxilian: i have 2 objects on my page from same plugin
i get JSAPIAuto from one to another
[16:35:48,843] uncaught exception: Invalid argument conversion from N5boost10shared_ptrIN2FB8JSObjectEEE to N11PointerAPIE
if i print object with console.log
before call the function with this object as argument
i saw the correct type
diorcety 08:07 :s
taxilian: like if the object wasn't known by the second PluginCore
taxilian 09:07 okay, I'm still a bit confused
so what you're saying is that you have a multi-mimetype plugin, right?
diorcety 09:07 exact
i have a getter in one JSAPIAuto with a function returning PointerAPI (which is JSAPIAuto) and another JSAPIAuto with a PointerAPI as argument
Object2.elem = Object1.elem
i print with console.log the returning object ... it's correct
taxilian 09:07 hang on a few minutes
diorcety 09:07 no problem :)
diorcety 09:07 taxilian: ?
taxilian 09:07 sorry, I'm back now
was speaking with my grandfather on the phone; he picked up a virus on his computer somewhere
so you can't pass in a JSAPI object as an argument
rather, it's not consistent
some browsers it will work, some not
well... acutally, you can, and it will work, but only if you use it as a FB::JSObjectPtr
diorcety 09:07 FB::JSAPIAuto
i use FB::JSAPIAutoPtr
of course
taxilian 09:07 this clarification has not changed my response at all
go read that post on stackoverflow
it explains the problem and suggests a workaround
diorcety 09:07 ok :)
crap :s
taxilian 09:07 eh, the workaround isn't that painful
diorcety 09:07 taxilian: thanks .. the initial issue is to pass pointer between plugin ... which is dangerous ... i used number ... i would make a better solution without exposing underlying value
taxilian 09:07 right. use an int or something, auto increment, only store weak_ptrs in the map
diorcety 09:07 taxilian: the issue with the way to save number on javascript side .. on 64 bits version it can be problematic
added to the fact a wrong manipulation on this number you can crash the plugin
the second solution can be interessting
taxilian 09:07 *never* try to pass raw pointers through javascript, as this could open security holes. If you use a normal number
and as long as you aren't passing raw pointer numbers you shouldn't have any problems whether you're 32 or 64 bit
diorcety 09:07 yes it's why i would change this behaviour
i will use weak map
taxilian 09:07 not a bad idea to occasionally have it go through and remove expired weak_ptrs from the map... technically it's a memory leak if you don't, though it's so small it is almost meaningless
diorcety 09:07 it's for link a video view with a "controller" ...
diorcety 10:07 taxilian: on javascript side all numbers are floating numbers no?
taxilian 10:07 actually it depends on the js engine
generally not
int32 if it fits, double if the number is too big for int32
diorcety 10:07 taxilian: Thanks for you help and your advices
taxilian 10:07 yw
diorcety 11:07 taxilian: so you said there is no issue to passing unsigned long to javascript and get it back (with same value)?
taxilian 11:07 max size to be really safe is a signed int32
diorcety 11:07 arf :s