|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 https://dev.firebreath.googlecode.com/hg/ 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||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.|
|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
|taxilian||14:10||how soon will you be releasing?|
|nirvdrum_||14:10||That's . . . lame.|
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|
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|
|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 =]
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.|
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
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.
|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.|
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.
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.
|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.
you're welcome :-P
|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.
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|
|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.
|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
|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.|
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.
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.
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|
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
|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
|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
|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
|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?|
|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
that won't build signals
since I don't have it included
|kalev||16:10||are you including all possible configurations?
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 =]|
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.
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_||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 :-/|
|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
|taxilian||18:10||JSObject was previously an AutoPtr<BrowserObjectAPI>
but that was inconsistent naming
|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
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|
|nirvdrum_||18:10||For a short while I thought it was fun to revisit this stuff.
It is not.
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.
|nirvdrum_||18:10||And I'm not afraid of low-level stuff.
I had pretty much the entire PIC opcode list committed to memory.
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.
|nirvdrum_||18:10||Now, C++ having like 13 different contexts for the "const" keyword is not fun.
That's borderline insane.
|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.
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