IRC Log Viewer » #firebreath » 2015-04-23

IRC Nick Time (GMT-7) Message
FizZ 02:04 hi
taxilian 09:04 walter_: I'm about to push a fix for the "crash"
but keep in mind it doesn't stop the exe from quitting
but keep in mind it doesn't stop the exe from quitting
it just makes it shut down the plugin first
it just makes it shut down the plugin first
walter_ 09:04 great
could you pls give me some hints, on how to migrate Firebreath 1.7 to 2.0
CmakeList.txt in project root - is the only file to be changed?
right now - cmake will not build with FB 2.0
right now - cmake will not build with FB 2.0
taxilian 09:04 fair enough; I'll pull your bug fix in
hmm
so I haven't really built a migration guide yet
the easiest way to figure it out might be to compare the fbgen/src directory in the master branch with the one in refactor
walter_ 09:04 I'll figure it out...
but
but
how much changes are required, like: CmakeList.txt, what about projectDef.cmake? I'm not there yet - but I guess some code changes aswell...
taxilian 09:04 yes, all of the cmake files will require changes
the cmake structure has changed a lot
the code changes are much more minor
the code changes are much more minor
mainly changes to better take advantage of c++11 features and optimizations
walter_ you followed that the exe will still quit, it will just shut down the plugin first, right? (I'm working on committing the fix)
walter_ 09:04 I don't mind if EXE quits.... That will be notified with "disconnect" message in extension...
The issue is - when EXE quites - that it shows crash message via Windows
taxilian 09:04 hmm. that is actually a crash, then, unless it's related to the assert..
that could be
walter_ 09:04 I guess the issue is when extension suddently disconnects - the EXE is not properly closing in this case
taxilian 09:04 this should help
it may just be the assert, but if there is a crash we need to track that down
I haven't tested this fix yet, btw
it may just be the assert, but if there is a crash we need to track that down
walter_ 09:04 I'll test it
walter_ 09:04 taxilian - calling properties via native-message should look like calling a function, right?
plugin.testString('abc').then(function() {
for some reason - I'm getting failed call from this promise
the communication looks like this:
--> {"cmdId":3,"type":"cmd","c":1,"n":1,"colonyId":0,"msg":"[\"GetP\",1,0,\"testString\"]"}
<-- {"c":1,"cmdId":3,"colonyId":0,"msg":"[\"success\",\"\"]","n":1,"type":"resp"}
<-- {"c":1,"cmdId":3,"colonyId":0,"msg":"[\"success\",\"\"]","n":1,"type":"resp"}
taxilian 10:04 calling properties? no, it's still just a getter, but returns a promise
so if testString is a property, you'll just do plugin.testString.then(function(val) { alert(val); })
walter_: ^
walter_ 10:04 I tried setter first
taxilian 10:04 setter looks no difference, since it can't return anything
heh. looks no different*
walter_ 10:04 yeah... great
yeah... great
Just tried it ;)
taxilian 10:04 =]
it's really quite a remarkable string of hacks, wouldn't you say? ;-)
walter_ 10:04 Could you give me a hint on one of converts in my code?
Could you give me a hint on one of converts in my code?
I have an argument to a function: const FB::VariantList& filters
I have an argument to a function: const FB::VariantList& filters
later I convert it to:
FB::VariantList filter = filters[i].convert_cast<FB::VariantList>();
basically it's just array - that contain array
taxilian 10:04 ahh; that now returns a promise
ahh; that now returns a promise
because it may be an asynchronous operation to convert to a VariantList
unless you know for sure that it's already an array
walter_ 10:04 I'm getting:
cannot convert from 'FB::Promise<FB::VariantList>' to 'std::vector<FB::variant,std::allocator<_Ty>>'
taxilian 10:04 right
exactly
exactly
in order to get an array from a jsobject we now have to call back into the page; in that case, it's an async operation
walter_ 10:04 but this is argument in one of my functions in pluginAPI.cpp
taxilian 10:04 so that returns a promise
yeah, JSAPIAuto is smart enough to resolve it for you before passing it in
yeah, JSAPIAuto is smart enough to resolve it for you before passing it in
walter_ 10:04 well, from JS I'm passing sth like: [["a","b"],["c","d"]]
well, from JS I'm passing sth like: [["a","b"],["c","d"]]
I should change argument into sth, like: const std::vector<std::vector<std::string>>& filters
correct?
taxilian 10:04 You could try it; it might actually work
JSAPIAuto is pretty smart about type conversion
JSAPIAuto is pretty smart about type conversion
but I'm not 100% certain if it will or not
you could also just use the Promise.done (or Promise.then) functions
if you have any operations that are long-running or async you should definitely learn how Promise<T> and Deferred<T> work anyway
very similar to javascript promises
I need to run an errand; probably be back in an hour or so
walter_ 11:04 I just tested your fix for crash...
It's not crashing anymore...
But in the same case - it's showing now "Assertion failed"
at WyrmColony.cpp --> line: 108
Expression: BrowserHost::getInstanceCountr() == 0