IRC Log Viewer » #firebreath » 2010-10-09

IRC Nick Time (GMT-7) Message
nirvdrum_ 14:10 So, is a project generated from trunk known to be broken?
Or have I just screwed up my upgrade somehow?
Argh, looks like I checked out dev, not default.
taxilian 14:10 dev is broken? it shouldn't be...
what problems are you having?
nirvdrum_: define "broken"
nirvdrum_ 14:10 PlugingWindowWin creates a WindowEvent with only 4 args when it requires 5.
taxilian 14:10 hmm; I don't remember that being changed recently; unless amackera has already pushed his windowless changes to dev, which I don't remember happening
nirvdrum_ 14:10 I'm really nascent with hg, so I may have screwed it up.
According to TortoiseHg though, dev hasn't been updated in 2 months.
taxilian 14:10 you're sure you're looking at and not the dev branch (which is no longer used)?
nirvdrum_ 14:10 Not sure at all :-)
taxilian 14:10 do you have changes that you're worried about in firebreath?
if not, do a hg update -C default
nirvdrum_ 14:10 Not particularly. I just want to retain the history for my existing project.
taxilian 14:10 that's not in the firebreath source control, though, right?
nirvdrum_ 14:10 Nay.
taxilian 14:10 better idea
nirvdrum_ 14:10 Yeah, that didn't work. Some sort of conflict.
taxilian 14:10 just put your projects folder outside of the firebreath source tree
nirvdrum_ 14:10 And my original copy was from the zip for 1.1.
taxilian 14:10 and pull down a new firebreath source tree =]
nirvdrum_ 14:10 So, I'm working on grabbing something from hg, moving my project into it, and tracking that going forward.
taxilian 14:10 that way there is no chance you'll get a weird copy
shouldn't need to put your project in it
keep your project seperate
nirvdrum_ 14:10 Heh. I actually want to version control FB. Someone should be able to check out my repo and build the plugin.
The file looks correct in that URL.
So I must have grabbed the dev branch.
taxilian 14:10 well, it's up to you
but that will make it a royal pain in the backside to update FB
much easier to keep it in two seperate repositories; even if they are both yours
nirvdrum_ 14:10 Yes, I've noticed :-)
taxilian 14:10 "check this out, then check this out, then run this from here"
nirvdrum_ 14:10 That's a fair point.
taxilian 14:10 easy
nirvdrum_ 14:10 So, what cmake incantation will allow me to do that?
taxilian 14:10 if you just use hg, you can even pull updates
the prep scripts accept two parameters
the first is the path to the projects directory to build
the second is the path to the build directory, where it should go
nirvdrum_ 14:10 Okay. I'll give that a whirl.
taxilian 14:10 keep in mind the projects dir needs to be a dir with one or more project directories in it
like examples or projects in the fb root normally is
nirvdrum_ 14:10 Now, which URL should I be cloning from? I'm surprised to see there are multiple instead of just multiple branches at the same URL.
taxilian 14:10 multiple branches was causing issues
hg just doesn't handle them well
nirvdrum_ 14:10 Really?
taxilian 14:10 how soon will you be releasing?
nirvdrum_ 14:10 That's . . . lame.
taxilian 14:10 yeah
when you clone, it checks out the most recently updated branch
nirvdrum_ 14:10 If I can build today and test it, I'll roll it out tomorrow. But, it's not a big deal for me to hold up either.
taxilian 14:10 when what we'd want is to always check out default unless specified otherwise
nirvdrum_ 14:10 Ahh.
That is annoying.
taxilian 14:10 well, if you need it completely stable, 1.2.2 is your best bet
and that's not currently easily accessible
nirvdrum_ 14:10 No tags in hg?
taxilian 14:10 if you need it pretty stable but can wait for me to fix bugs you may come across (or help me fix them) then get 1.3 beta
yeah, there is ai tag
you could do that
nirvdrum_ 14:10 I'm fine tracking 1.3 as long as it's not majorly broken or going to require a huge rewrite from 1.2.
taxilian 14:10 if you really want to have the latest and greatest, which honestly I *think* is stable, but won't guarantee, then go for dev
there are a couple of breaking changes in 1.3
which should be the last
but they are minor
just a couple of things renamed
nirvdrum_ 14:10 If I make them now, that's fine. I just don't want to deal with a string of them week-on-week.
taxilian 14:10 shouldn't be an issue
nirvdrum_ 14:10 Cool.
taxilian 14:10 I'm trying really hard to make sure that 1.3 is the last set of real changes
but we decided that we needed to make these changes for consistency
personally, I would rather have you on dev, because then if there are any issues you'll find them quickly and I can fix them =]
nirvdrum_ 14:10 There were a bit from 1.1. Not too bad to deal with, but then again, I haven't gotten a successful build yet either :-P
taxilian 14:10 but obviously that is a little bit of a selfish reason
nirvdrum_ 14:10 Any chance you can blow away the "dev" branch in the default repo?
Might prevent confusion like I ran into.
taxilian 14:10 can't figure out a way to make it go away
wish I could
short of recreating the whole repo, anyway
which would then cause problems for anyone who has cloned it
nirvdrum_ 14:10 Well, the only reason I'm even looking at upgrading at this point is I have like 3 URLs out of 10s of thousands that seem to crash my plugin without fail. So, I'm hoping like hell some of the memory fixes that landed will make the problem go away.
If not, at least I'm running on a recent version of FB :-P
taxilian 14:10 hehe. trust me, there are enough fixes since 1.1 that you definitely want to switch… =]
if you use multiple threads you'll definitely want dev
nirvdrum_ 14:10 I'm impressed I've run into as few issues as I have.
taxilian 14:10 there are some very nice fixes and features in there to better support threading
I am too, honestly =]
nirvdrum_ 14:10 Heh.
Does 1.3 have the multi-byte string stuff in it?
taxilian 14:10 but then, I probably feel like it's less stable than it is because I've fixed so many minor edge cases from there
nirvdrum_ 14:10 It'd be nice to drop out mine.
taxilian 14:10 though there have been some minor issues reported with it, they seem to be edge cases
nirvdrum_ 14:10 Naw, 1.1 has been really stable for us.
taxilian 14:10 good
I'm fairly confident that 1.2.2 is more stable
and 1.3 dev even should be *fairly* stable, it's just not as well tested as the releases
nirvdrum_ 14:10 So, my immediate goal is to fix crashing in Chrome. Within the next month or so I'd like to try to port what I have into something that'll work for Safari.
Then I'd like to merge my SnapsIE codebase (IE MSHTML thing) into one unified source tree.
taxilian 14:10 yeah, that would be cool
the new improvements in 1.3 for cross-threading might come in handy
you can make synchronous or async calls on the main thread from any other thread… more or less arbitrarily
through a templated function
on browserhost
using boost functors
nirvdrum_ 14:10 Oh. I recall some of that being funky. But, I think I was going main thread -> spawned thread, no the other way around.
I ended up doing a callback, which really didn't work out as well as I had hoped.
Quite the hack to make it all work.
taxilian 14:10 :/
nirvdrum_ 14:10 I wanted JS to instruct the plugin to take a screenshot and hand the data back. Since I couldn't make it block, I have to hand back a filename to check. Then the caller (Selenium in this case), just keeps polling until the screenshot file exists, doing what it needs to at that point.
taxilian 14:10 makes sense
couldn't you have selenium wait for a callback function to tell it that the file is there?
nirvdrum_ 14:10 IE let me make the call synchronously. The browser UI locks up doing that time, but the screenshot gets taken just fine.
taxilian 14:10 yeah, I remember you telling me about it
nirvdrum_ 14:10 Well, Selenium is a Java server calling into a JS control file for browser automation. That JS control file was what was interacting with the screenshot. Selenium itself expects to make that JS call and get back a value.
If I made the control JS busy-wait, the browser still locks up. But once a value is returned, the browser gets shut down.
So, there's no opportunity for an async callback, since the browser might not even be running any more.
Not really fun.
taxilian 14:10 hmm. my understanding is that at least some automation frameworks, such as windmill, had some way of testing async things as well, for ajax calls and such
nirvdrum_ 14:10 Yeah, there is some way of doing that, but it would have required a lot of modification of virtually untested JS.
And they do some really gnarly stuff to make that happen. Basically an infinite loop of polling callbacks.
taxilian 15:10 ahh
eventually I plan to set up some automated tests for FireBreath
nirvdrum_ 15:10 And most (all?) basically inspect the DOM to for a value to change. There isn't really a re-entrant codepath that I'm aware of. So, I'd have to base64 encode the image and attach it to the DOM. Doable of course, but strange.
taxilian 15:10 to help prevent regressions
I would never pass the image through JS; much better to save it to a file
I would just use JS to notify which file it was
and that it was there and finished
nirvdrum_ 15:10 Yeah. So, the server handles all that.
With SnapsIE, since the call doesn't return until the file exists, the selenium server has it easy.
taxilian 15:10 yeah
nirvdrum_ 15:10 In my case, the call almost always returns before the file exists. So, the server has to busy wait. But even that's not enough because the file could be partially written to.
Oh yeah, keeping the project outside the FB source tree is soooooooooo much nicer.
taxilian 15:10 hehe
you're welcome :-P
nirvdrum_ 15:10 Thanks.
taxilian 15:10 was one of the first things I fixed when I got to where I could work on FB again
nirvdrum_ 15:10 Now to reorganize and update my old code.
Boost will be the fun one. I had to custom build a few libs when I was last doing this.
taxilian 15:10 which ones?
and why did you need to custom build them?
nirvdrum_ 15:10 thread was a big one. Prior to 1.44.0 it just didn't work with VS 2010.
So, I had to track trunk for a little while.
taxilian 15:10 you probably don't need to worry about that, then
nirvdrum_ 15:10 Then I think there were a couple others that just weren't bundled with FB that I needed. datetime comes to mind.
taxilian 15:10 fb boost is 1.44
nirvdrum_ 15:10 Oh, sweet.
taxilian 15:10 add_boost_library(datetime) in your PluginConfig.cmake
oh, and you'll want to use dev
nirvdrum_ 15:10 That was going to be my first patch. I guess I don't need to do that now :-P
taxilian 15:10 datetime, system, filesystem, and a couple others are supported
nirvdrum_ 15:10 Great. The list was pretty anemic with 1.1.
taxilian 15:10 the bad news is that the size of the download has tripled since 1.1… :-P
however, from survey results nobody seems to be worried about it
or rather very few
nirvdrum_ 15:10 Bandwidth is cheap. I must have killed close to 30 hours getting and waiting for boost to build.
Tracking down the bug in VS2010 was painful. Discovering it was fixed in trunk already was almost worse.
taxilian 15:10 that would be exactly why I keep putting it in firebreath =]
ask me next time =]
nirvdrum_ 15:10 I had. You didn't have the problem because you were on 2008 I think.
And the dudes in #boost would say "works for me" without them telling me they were running on trunk.
taxilian 15:10 ahh
sorry :-/
nirvdrum_ 15:10 It had to do with an improperly generated tlb file or something.
Anyway, 'twas annoying.
taxilian 15:10 I believe that
nirvdrum_ 15:10 I forgot what long compilations were like, too.
boost is like 2.5 GB if you build the whole thing.
Took like 30 min.
Looks like I'm using boost/format for string formatting. I don't suppose FB pulls that in, does it?
taxilian 15:10 I think so
if it doesn't, let me know and I'll add it
nirvdrum_ 15:10 Okay.
taxilian 15:10 it looks like it's there
that doesn't require any libraries, just headers
nirvdrum_ 15:10 Wow. The #pragma deprecations are an awesome touch.
taxilian 15:10 ?
yeah, we were hoping that would make it easier to switch over
however, keep in mind that that won't catch everything
most things that you were using FB::JSObject with (probably all, actually) should now be FB::JSObjectPtr
FB::BrowserHost is now FB::BrowserHostPtr
nirvdrum_ 15:10 Yeah, I see.
I regenerated a project and have been doing WinMerge to catch stuff.
But, I missed something and the pragma helped.
taxilian 15:10 oh, good
and yeah, that's a *really* good idea
nirvdrum_ 15:10 One of my biggest gripes with Ruby is that no one in that community seems to know what deprecated means or care.
And since it's a dynamic language, they've decided the best way to handle this situation is to print out warning messages to STDERR.
Which is really awesome when it's used in a script via cron.
Because I get an email everytime it gets run.
taxilian 15:10 yeah, PHP does the same thing
nirvdrum_ 16:10 Alright, looks like I'm finally ready for my first patch submission. Do I just clone in googlecode or is there a way for me to submit the patch based upone my already checked out repo?
Btw, if RTFM for mercurial is the appropriate answer, I'll go do that.
taxilian 16:10 nirvdrum_: clone in googlecode is the easiest
what does the patch do?
nirvdrum_ 16:10 Bump the WINVER from Win2k to Win XP.
A bunch of APIs aren't available otherwise.
taxilian 16:10 ahh
yeah, that's fine
in fact, just tell me what to change on that
and I'll change it
I don't need a formal patch submission for everything =]
nirvdrum_ 16:10 Change the 0x0500 values to 0x0501 in targetver.h
And update the comments from "Vista" => "XP"
taxilian 16:10 done in dev
nirvdrum_ 16:10 Thanks.
taxilian 16:10
verify that I did it right, please
nirvdrum_ 16:10 That'll do it.
I guess more controversial would be changing the IE version from 0x0700 to 0x0600. I think those two are API compatible.
taxilian 16:10 they must be
since FireBreath works fine with IE6 =]
nirvdrum_ 16:10 Yeah, that's what I thought. So, might be worth dropping that.
kalev 16:10 hey, any chance to add boost::signals to the already long list of bundled boost libs?
(you said you don't need a formal patch submission for everything, so I'm pushing my luck :)
taxilian 16:10 kalev: any chance you'd be willing to do the legwork for it? =]
nirvdrum_ 16:10 Now, for some inane cmake questions. I got around all this by versioning things I probably shouldn't have been, rather than handling it in cmake files.
taxilian 16:10 it wouldn't be hard
nirvdrum_ 16:10 How can I go about adding gdiplus to my plugin's external dependencies list?
kalev 16:10 yeah, I'll do that
taxilian 16:10 kalev: actually, I'll add the files
you just set up the project
it'll be good practice =]
nirvdrum: First you have to figure out how to best include it with cmake
all platforms?
kalev 16:10 taxilian: sounds good
nirvdrum_ 16:10 Well, if I knew that, I'd just do it :-P
taxilian 16:10 nirvdrum: do you need it for all platforms?
nirvdrum_ 16:10 It's a Windows-only thing, but I only build for Windows right now. So, "yes" I guess.
If I ever get to Mac, I'm going to have to restructure a lot more anyway.
taxilian 16:10 ok; do you have the libraries already built or do you need to build them as part of your project?
nirvdrum_ 16:10 They're Win32 SDK things. They're just not added by default.
taxilian 16:10 nirvdrum_: ok, so all you would do in visual studio is add something like "gdiplus.lib" to the link inputs?
nirvdrum_ 16:10 Yeah, I think. It's been a while, but that sounds about right.
taxilian 16:10 then all you need to do is add those to the target_link_libraries call
without the .lib
it'll probably be in Win/pluginDef.cmake
kalev: the files you need are there. I recommend looking at some of the other boost libs to see how to create the cmakelists file for it correctly
kalev 16:10 allright, thanks
taxilian 16:10 kalev: it's the dev repo that you need, btw
though what is in dev will probably go into trunk in the next week or so
probably monday
kalev 16:10 taxilian: I suspect it's in the boost repo actually :-)
taxilian 16:10 kalev: well, yes, but the dev repo is the one that uses a late enough version of the boost repo to get those files =]
if you get trunk, it won't pull the latest boost libs
kalev 16:10 right.
nirvdrum_ 16:10 Hmm . . . didn't work, but at least I have a starting point now.
taxilian 16:10 nirvdrum_: good rule of thumb for dealing with cmake; when something doesn't do what you expect, go figure out what it did in the visual studio project and see if that makes it clean
in this case, go look at the linker settings
and see what ended up there
kalev 16:10 taxilian: okay, done, just copied over boost_system's CMakeLists.txt and changed system->signals in that file
taxilian 16:10 kalev: yeah, that's probably all that is needed. =] make sure it builds and we're good
kalev 16:10 could you update the .hgsubstate file in dev repo? I'm on a slow connection and don't want to pull down dev repo
taxilian 16:10 you don't have to update that yourself
it should be updated automatically
oh, I see what you're saying
kalev 16:10 well, I was on stable repo and just committed directly to boost repo
taxilian 16:10 yeah, if you push the changes up, I'll pull them into dev
kalev 16:10 I already pushed.
taxilian 16:10 did you make sure it builds?
kalev 16:10 yep
taxilian 16:10 I see it
kalev 16:10 builds fine on Linux.
thanks, I'll test other platforms some other day
taxilian 16:10 meh, i'll test them all
they are building
oh, wait…
that won't build signals
since I don't have it included
kalev 16:10 are you including all possible configurations?
taxilian 16:10 can fix
well, I can fix that too =]
checking to make sure it works on my system, then will push it up =]
nirvdrum_ 17:10 Did win_common.h go away or get moved?
Or pluginCore\windows for that matter
Ahh, found it.
taxilian 17:10 huh. you really were on an old version =]
nirvdrum_ 17:10 Heh.
So, that's all in a namespaced PluginWindow project now, eh?
What's the point in namespacing it if the source files still come out for the firebreath source tree?
taxilian 17:10 I don't understand the question?
it isn't in the PluginWindow project for namespace reasons; that's not really a good place for it, but we haven't determined a better one yet
PluginWindow exists to provide a project/plugin specific project for PluginWindow objects, since we conditionally compile them based on PluginConfig settings
nirvdrum_ 17:10 Well, I have a MOGO_PluginWindow project in my solution, but all the files link back to the Firebreath source tree. They're not generated in my project.
So, modifying them means modifying firebreath.
taxilian 17:10 yes
but if you were on mac
you would have different files included in that project
actually, one of the things on my to-do list is to find a good way to allow those files (and others, such as the .rc or .rgs) to be overridden in a specific project
without modifying firebreath
nirvdrum_ 17:10 I have Mac and Windows subdirectories though.
taxilian 17:10 on mac, you have a choice between 2 event models and something like 3 or 4 drawing models
if you disable those, it doesn't compile in those files
nirvdrum_ 17:10 Anyway, the MOGO namespace seems misleading because multiple projects would actually use the same files. I also naively assumed the namespace meant I could change that stuff.
But, it really should be read-only it seems.
taxilian 17:10 yeah, it should
open to suggestions how better to show that
it is specific to your project, but it is set up based on your pluginconfig
not intended to be changed
nirvdrum_ 17:10 No idea. Probably me just not really understanding what that namespace is for anyway.
So, I wanted to modify win_common.h, but that's a no go. I'll have to find a better way of doing that.
Ooh I'm getting close to a clean build :-)
taxilian 17:10 so the problem we run into with modifying win_common is that some of the projects using it are not compiled specific to your plugin
thus if you modify it in a file specific to your plugin, it gets modified for everything
nirvdrum_ 17:10 Dinner. bbiab
nirvdrum_ 18:10 Awesome. Down to an issue with boost::thread and scheduling/calling a callback.
Before I get sucked into a rat hole, does the bundled boost::thread not support constructing threads a function and arg list?
I'm getting a compilation error about that.
taxilian: Any idea? (And sorry to keep bugging you)
nirvdrum_ 18:10 Oh, looks like I got it now.
Seems I needed to update my callback definition.
And VS didn't really give me a great error message.
taxilian 18:10 nirvdrum_: template error messages are just always evil :-/
nirvdrum_ 18:10 Yeah.
taxilian 18:10 when you say scheduling / calling a callback… what are you referring to?
callback into JS?
nirvdrum_ 18:10 I was passing around a const ref to my JSObject for the callback, but that doesn't seem to work any more.
I changed it to JSObjectPtr and that at least allowed it to compile, but I doubt that's the right thing to do.
taxilian 18:10 needs to be a JSObjectPtr
that is
nirvdrum_ 18:10 Oh. Okay.
taxilian 18:10 JSObject was previously an AutoPtr<BrowserObjectAPI>
but that was inconsistent naming
nirvdrum_ 18:10 Gotcha.
taxilian 18:10 so we renamed BrowserObjectAPI to JSObject and the shared_ptr to it is JSObjectPtr
you could run into a similar problem with BrowserHost
nirvdrum_ 18:10 There was one other place where I wanted to cast the plugin object to my class type. Is it cool to just call .get() and do the cast or is there a better way of doing that?
taxilian 18:10 you should never use a BrowserHost*, instead use a BrowserHostPtr
never, *ever* do .get
use FB::ptr_cast<destination_type>()
otherwise it could have inconsistent reference count in the shared_ptr
nirvdrum_ 18:10 Well, it's only ever used locally, so I was hoping the count couldn't get screwed up.
MogotestPluginAPI* api = (MogotestPluginAPI*) this->getRootJSAPI().get();
taxilian 18:10 which could result in things exploding and undesirable bills getting signed into law
nirvdrum_ 18:10 Is what I have now.
taxilian 18:10 do *not* do that
for all our sakes
nirvdrum_ 18:10 Fair enough. Guess I need to sharpen up on the boost pointer stuff.
taxilian 18:10 instead, us boost::shared_ptr<MogotestPluginAPI> api(FB::ptr_cast<MogotestPluginAPI>(getRootJSAPI()));
you could also typedef your own MogotestPluginAPIPtr if you want
nirvdrum_ 18:10 I'm starting to recall what it was I hated about C++ so much :-P
taxilian 18:10 lol
nirvdrum_ 18:10 For a short while I thought it was fun to revisit this stuff.
It is not.
taxilian 18:10 lol
I like C++
as long as you know the rules, you know exactly what is happening
nirvdrum_ 18:10 Well, I'm building fine now. But, I have new runtime errors to debug.
The rules for C++ are incredibly obtuse.
taxilian 18:10 lol
well, yes
nirvdrum_ 18:10 And I'm not afraid of low-level stuff.
I had pretty much the entire PIC opcode list committed to memory.
taxilian 18:10 hehe
I've been meaning to learn PIC assembly for about 6 years now
never found a good enough reason
nirvdrum_ 18:10 My old company was a hardware-device manufacturer.
And I wrote a bootloader for one of the PICs. But, the only real way to debug it, short of a logic analyzer, was to do a hex dump and decode the commands.
So, I became pretty adept at reading and writing opcodes in hex.
Fun stuff.
taxilian 18:10 ...hehe
nirvdrum_ 18:10 Now, C++ having like 13 different contexts for the "const" keyword is not fun.
That's borderline insane.
taxilian 18:10 lol
nirvdrum_ 19:10 Ahh, my new runtime error is that I'm apparently calling something from the wrong thread.
That's pretty helpful.
I'll have to look into how this FBLOG stuff works. Seeing that message would have help a lot.
I like frameworks that preemptively tell me when I'm screwing up.
taxilian 19:10 hehe
so if you really need to call something from a different thread
there are ways to do so
look at BrowserHost, the methods you need are ScheduleOnMainThread and CallOnMainThread
the first is async, the second will wait for the call to be made and return
I gotta run, be back Monday
good luck