IRC Log Viewer » #firebreath » 2011-03-21

IRC Nick Time (GMT-7) Message
rstanwar 05:03 hi
i downloaded firebreath how to build it using visual studio 2008
pls send me reply on [email protected]
taxilian 09:03 morning all
EL45 10:03 Hello everyone. I have successfully build and compiled my plugin for windows. However, when I try and compile on Mac i receive:
invalid initialization of non-const reference of type 'FB::JSObjectPtr&' from a temporary of type 'boost::shared_ptr<FB::JSObject>'
I can't seem to track down the problem. I receive the error once I make a call to registerMethod
Any suggestions?
dan2 10:03 taxilian: you around?
taxilian 10:03 EL45: do the sample plugins compile?
dan2: more or less
EL45 10:03 Yes they do
taxilian 10:03 EL45: could you pastebin me the file that the error is on?
!findfile WinMessageWindow
FireBreathBot 10:03 Found 2 matching file(s) in the master branch. First 2 are:
EL45 10:03 Condensed version of the code causing the problem
Error comes from MethodConverter.h
taxilian 10:03 EL45: make FB::JSObjectPtr& a const
EL45 10:03 That solved it. Thank you so much. You have been really helpful.
taxilian 10:03 np
linearray 10:03 duplicates my xcode build targets
by now I have every target 5 times
taxilian 10:03 linearray: try deleting your build di
and running prepmac again
linearray 10:03 ah yes, thanks
taxilian 10:03 I've never actually seen that happen before, though
if it happens again, let me know
we should try to figure out why
linearray 10:03 will do
genarek 11:03 Hi every one. I hve a little question. If you could helpt me out, I'd appreciate it.
I am trying to use the logging library in the 3rdParty/lib in a debug version of a plugin I am working on. The platfor will be Linux. How do I do this?
It doesn't have to be the logging library. Is there any way to add stuff to the linker? I tried to concatenate -lmylibraryname to the FBLIBS. Didn't work...
which cmake file should I edit?
Ok, I guess I'll just bug you people by email... :D
taxilian 11:03 *sigh*. gone for 10 minutes...
neilg_ 12:03 Hey all
taxilian 12:03 hey neil
there are some significantish improvements to the coreanimation stuff in the 1.5 branch
you may want to check out
neilg_ 12:03 Oh? Yes, I'll definitely take a look at that - I'm still having issues that I haven't quite tracked down. :(
I don't believe the fault is FB though... Even so, it's worth checking out!
Thanks =)
taxilian 12:03 well, ICA is (we think) properly supported now
wanna see something fun I did over the weekend?
!find htmlLog
FireBreathBot 12:03 Found 1 possible matches. Displaying 1
/^void FB::BrowserHost::htmlLog(const std::string& str)$/ (f) found in src/ScriptingCore/BrowserHost.cpp:
taxilian 12:03 I'm having way too much fun with this bot… :-P
neilg_ 12:03 Got to love new toys ;)
That's awesome though. Good work!
And the same to ICA. That's very good news!
taxilian 12:03 I will probably put 1.5 in RC as soon as the new PluginWindow stuff is done
also FIREBREATH-11, I think
FireBreathBot 12:03 FIREBREATH-11: Summary: Using a DOCTYPE definition in the HTML page breaks IE 9
FIREBREATH-11: Assigned To: richard
FIREBREATH-11: Priority: Major, Status: Open,
taxilian 12:03 wait, no, FIREBREATH-12
FireBreathBot 12:03 FIREBREATH-12: Summary: Plugin stops working if moved around in the DOM on IE
FIREBREATH-12: Assigned To: richard
FIREBREATH-12: Priority: Minor, Status: Open,
taxilian 12:03 yeah, that one
neilg_ 12:03 What, FIREBREATH-12?
FireBreathBot 12:03 FIREBREATH-12: Summary: Plugin stops working if moved around in the DOM on IE
FIREBREATH-12: Assigned To: richard
FIREBREATH-12: Priority: Minor, Status: Open,
neilg_ 12:03 Heh. :)
taxilian 12:03 =]
FireBreathBot 12:03 FIREBREATH-9: Summary: make_method modified to take 15 parameters
FIREBREATH-9: Assigned To: richard
FIREBREATH-9: Priority: Major, Status: Closed,
taxilian 12:03 that's a bit better… not so slow anymore
jshanab_wcw 12:03 I have a FB plugin that connects to a C++ program with an embedded Mongoose web server. Is anyone here familiar with mongoose? It appears as if when a web request comes in, it stops other responses in progress.
taxilian 12:03 not a clue
jshanab_wcw 12:03 :-/ thanks
taxilian 12:03 is this running inside the plugin process, then?
or an external process?
jshanab_wcw 12:03 The web server runs on a seperate box, the plugin uses a loop to read from the socket. It is a strange inherited beast returning an infinitly long web page from a get video frames. I am trying to issue a second request to "seek" the file and it appears that as soon as the request comes in, before I hit the handler, it just stops sending data.
taxilian 12:03 ahh
yeah, that sounds painful
my bet is that the webserver doesn't thread well
jshanab_wcw 12:03 A web server would be quite useless if the download of a file was broken by a second request to the same server, it can't be intended that way.
neilg_ 12:03 Sure. I'm with Richard - that sounds painful!
taxilian 12:03 but that doesn't mean that the implementation doesn't have some check to force it to only have 1 active stream at a time
I doubt the problem would be mongoose itself
jshanab_wcw 12:03 It has a connection limit default to 10 but set to 100.
taxilian 12:03 but I have seen many devices that stream video that don't figure they can handle multiple video streams, so they do weird things to shut off the old one when the new one starts
jshanab_wcw 12:03 But in this case I am the handler code on the other box (paints target on back) I recive the callback when the uri is called and return the "multi-part mime" header then enter a loop sending packets. This works surprizingly well, I send a whole hour without issue
taxilian 12:03 and what happens when you make the other request?
jshanab_wcw 12:03 I try tracing it but it has eluded me. The result = conn.write(...) that sends data immediatly returns false and I exit on that condition, which we have taken to mean the reciver is no longer there.
taxilian 12:03 huh
jshanab_wcw 12:03 let me pastebin.....
taxilian 12:03 yeah, I don't have any idea; I'd need a lot more background and more time than I have currently
jshanab_wcw 12:03 I cut out a bunch of stuff to keep it small, line 41 returns 0 and causes an immediate exit in this thread, when I make a new connection to another uri the server handles.
taxilian 12:03 I don't have any idea what "conn" is or how it works; I'd dig into the code and find out what would cause it to return 0
this is in the mongoose handler code?
jshanab_wcw 12:03 Ok, Thanks for having a look. I am just running out of ideas here :-).
Yes the mongoose binds uri's to callbacks and the conn is the handle tothe incoming connection, anything you send to it is put in the response
taxilian 12:03 okay; well, open the mongoose code and find out for sure what would make it return 0
it may well be that for some reason there is a bug in your client that causes it to disconnect when you send the other connection
try sending the command using curl seperate from the browser
jshanab_wcw 12:03 Oh, great idea
FireBreathBot 13:03 JIRA issue issue created by jzablotny
FireBreathBot 14:03 Commit 1452462 on firebreath-1.4 by Richard Bateman: "FIREBREATH-13 - invalidateWindow w/ IE windowless calls on m..."
Commit 6b02fae on master by Richard Bateman: "FIREBREATH-13 - invalidateWindow w/ IE windowless calls on m..."
taxilian 14:03 1452462e
FireBreathBot 14:03 1452462 by Richard Bateman: FIREBREATH-13 - invalidateWindow w/ IE windowless calls on m
JIRA issue issue resolved by richard "I believe this is fixed in"
neilg_ 14:03 Hey taxilian, what changed with the ICA over the weekend?
I've updated, I just fixed my first git merge errors too so I'm feeling quite proud of myself ;)
taxilian 14:03 lol. well done ;-)
umm… lots changed, really :-P
neilg_ 14:03 I know before I updated I never got ICA, I always got CA - will that have changed?
taxilian 14:03 !findfile PluginWindowMacICA
FireBreathBot 14:03 Found 2 matching file(s) in the master branch. First 2 are:
taxilian 14:03 !findfile PluginWindowMacCA
FireBreathBot 14:03 Found 2 matching file(s) in the master branch. First 2 are:
taxilian 14:03 so you can now get the PluginWindowMac object and call getDrawingModel to find out which it is
rather than just relying on a cast
neilg_ 14:03 Aha! That's definitely going to be useful
taxilian 14:03 in many cases it may not immediately matter to you
if you get a CA, you can getDrawingPrimitive to get the m_layer
FireBreathBot 14:03 Found 1 matching file(s) in the master branch. First 1 are:
taxilian 14:03 if you want to do an autoinvalidate instead of calling invalidate, that's now supported
just tell it how many times per second to invalidate in the StartAutoInvalidate method
!find StartAutoInvalidate
FireBreathBot 14:03 Could not find any tags matching StartAutoInvalidate
taxilian 14:03 strange
!find StartAutoInvalidate
FireBreathBot 14:03 Could not find any tags matching StartAutoInvalidate
taxilian 14:03 huh
well, I can
but anyway, if you call InvalidateWindow after you finish drawing it should all just work
when using CA
QD and CG, of course, you call it so that it will call you back to draw
the timer thing is kinda cool, though
taxilian 15:03 well, I'm off to school
see you all when I get back online there
sabotaged|wk 15:03 hmm
taxilian, is there a reason you do a synchronous call instead of async for fix of firebreath-13?
seems to be creating a deadlock: PluginWindowlessWin's m_mutex is locked on worker thread by call to Invalidate Window, worker thread is waiting for main thread to finish syncrhonous call. main thread is waiting on m_mutex
FireBreathBot 15:03 JIRA issue issue commented by jzablotny "is there a reason we need to use a synchronous call to the main thread? looks like this is creati..."
FireBreathBot 15:03 JIRA issue issue commented by richard "hmm. interesting. okay; I may need to rework the async schedule a bit. I'll try to make that c..."
taxilian 15:03 sabotaged|wk: yeah, there is a reason, just not a good one; ScheduleOnMainThread doesn't allow a normal pointer, since the ptr could then go away before the call completes
but in this case, I don't have a shared_ptr
sabotaged|wk 16:03 yeah, i guessed that might be the problem
taxilian 16:03 however, I can work around it
it's just a bit of a pain
I hadn't realized it would make the call immediately
begs the question, though
should I make it async, or remove the mutex from that call?
sabotaged|wk 16:03 hmm
could move the mutex to just guard getting the window size
taxilian 16:03 yeah
sabotaged|wk 16:03 m_invalidateWindow's setter doesn't even aquire a mutex
so that's thread unsafe already
unless boost functions are thread safe?
taxilian 16:03 !find m_invalidateWindow
FireBreathBot 16:03 Found 1 possible matches. Displaying 1
/^ InvalidateWindowFunc m_invalidateWindow;$/ (m) found in src/PluginAuto/Win/PluginWindowlessWin.h:
taxilian 16:03 oh
it doesn't need a mutex
because it happens before anything has a reference to the window
so there is no possibility of it being called on another thread
sabotaged|wk 16:03 ok
taxilian 16:03 looking it it now
my professor is late :-P
sabotaged|wk 16:03 what class?
taxilian 16:03 compilers
I finally finished the %$#%$# semantic analysis phase today, so now I just have intermediate code generation and then target code generation to do
which will hopefully go a lot faster
!findfile shareable
FireBreathBot 16:03 Found 1 matching file(s) in the master branch. First 1 are:
taxilian 16:03 sabotaged|wk: just an FYI, what I'd like to do is expand your windowless example a bit and put it in its own git repo
rather than inside FireBreath
sabotaged|wk 16:03 ok sure
i wasnt sure where to put it
taxilian 16:03 fair enough; I should have been more specific in my request =]
I envision having a project which is nothing but submodules that you check out if you want to just get all the examples
sabotaged|wk 16:03 i think i also somehow messed up and made my branch off master, even though i intended 1.4
taxilian 16:03 it looks like it, yes
sabotaged|wk 16:03 ugh learning git would be a lot easier if i had to use it everyday
taxilian 16:03 heh. yeah, I know what you mean
it's … different, at first
FireBreathBot 16:03 Commit ababdfe on firebreath-1.4 by Richard Bateman: "FIREBREATH-13 Changed invalidate to async cross-thread call"
Commit 6c59820 on master by Richard Bateman: "FIREBREATH-13 Changed invalidate to async cross-thread call"
taxilian 16:03 sabotaged|wk: try that
sabotaged|wk 16:03 ok
taxilian 16:03 sabotaged|wk: also, on windows I'm pretty sure 1.5 is nearly done
only one more thing I'm hoping to add to it
FireBreathBot 16:03 FIREBREATH-12: Summary: Plugin stops working if moved around in the DOM on IE
FIREBREATH-12: Assigned To: richard
FIREBREATH-12: Priority: Minor, Status: Open,
FireBreathBot 16:03 JIRA issue issue commented by jzablotny "looks to be working well now, thanks!"
JIRA issue issue closed by richard "Cross-thread problem fixed"
sabotaged|wk 16:03 hmm, trying to figure out how this ShareableReferece is supposed to work
won't it just go out of scope and destruct after you call ScheduleOnMainThread?
oh that's right, it's a synchronous call
taxilian 16:03 no, not until after the call completes
Schedule is not syncrhonous
Call is
but it's a shared_ptr, so it doesn't go out of scope until the call finishes
and it's not actually used anyway; it's just a dummy object to pass through =]
sabotaged|wk 17:03 yeah, i'm just wondering what the purpose is
taxilian 17:03 the purpose is that 99% of the time, you should have something real to pass in there
sabotaged|wk 17:03 i can see if you passed in shared_from_this, and then kept a weak ptr of it
taxilian 17:03 but in this case you don't need to =]
there is no shared_from_this on that class
sabotaged|wk 17:03 yeah i know
why dont you need to in this case?
taxilian 17:03 because the BrowserHost goes away before the FBControl object does
so there is no way that the async call will occur after fbcontrol goes away
sabotaged|wk 17:03 ok
taxilian 17:03 I actually could have just passed a boost::shared_ptr<int>() or something like that
since it doesn't ahve to be valid
but this is a little more "legit", I suppose
not that it matters
I'll revisit it later after I've fixed some other things
sabotaged|wk 17:03 might not matter technically but its a bit confusing. maybe just change the variable name to dummyRef or something
taxilian 17:03 file an issue =]
taxilian 17:03 bbl
Jesse_ 19:03 Hello all, Had a Firefox RC1 & 2 question regarding the scripting object. Seems that has changed from a JSAPI-Auto Javascript Object to a object HTMLObjectElement. Which according to FIREBREATH-11 is an issue with validation. Anyone else seen this behavior?
FireBreathBot 19:03 FIREBREATH-11: Summary: Using a DOCTYPE definition in the HTML page breaks IE 9
FIREBREATH-11: Assigned To: richard
FIREBREATH-11: Priority: Major, Status: Open,
taxilian 19:03 Jesse_: I'm confused; what exactly is going on?
FB-11 only relates to IE9
Jesse_ 19:03 Hi, thanks for replying. So previous to FF 4 RC1 update calls to scriptable plugin object worked fantastic. Since the update (which includes FF RC2) JS calls fail. The object used to be JSAPI-Auto Javascript Object and now it seems to be HTMLObjectElement, That is the reason why I was referenceing bug 11
taxilian 19:03 that would be completely unrelated; I haven't seen the issue
what OS are you on?
Jesse_ 19:03 win 7 64bit home
taxilian 19:03 hmm. we've tested RC2 on Mac, not on windows yet
have you tried FBTestPlugin, or just your own?
Jesse_ 20:03 Just my own. I have been updating to the latest firefox every chance I get just to stay bleeding edge. Didnt really worry too much but ive heard FF 4 will be final tomorrow.
I will try the test plugin
Like I said this behavior just popped up as of RC1
taxilian 20:03 oh, RC1 definitely was working fine
RC2 I'm not sure of
Jesse_ 20:03 Yeah, I wasnt seeing that. I must be doing something wrong. As soon as I upgraded off of beta releases to the RC1 ~ a week ago my plugin started failing. Well I will try the test plugin. Thanks for your time. Much appreciated
taxilian 20:03 let me know
Jesse_ 20:03 will do
taxilian 20:03 I can tell you 100% for sure that we've done a lot of testing on RC1 and it was working, though
it should still be a JSAPI object
I'm also downloading RC2 to try it out here
Jesse_ 20:03 Thanks. I will also try it on an older xp machine for the heck of it.
taxilian 20:03 Jesse_: Win7 Ultimate x64 it works fine
Jesse_ 20:03 I just updated my older box (win xp 32bit) to FF4 RC1 and it works just fine with my plugin. So some other variable in the mix I am not aware of. I will try to complete uninstall FF and start from scratch. I will keep at it. Thanks again.
taxilian 20:03 might not be ff
it might be something with the registration of your plugin
just a thought
Jesse_ 20:03 I bet your right. My guess is firefox isnt broken, I suspect my code first. But the HTMLObjectElement being returned brought me to the bug 11, just thought maybe someone else has seen it.
have to drop, gonna toy with it more. Thanks again. If I figure it out ill be sure to let you know.
taxilian 20:03 … stil don't understand how HTMLObjectElement seemed related to FB-11