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

IRC Nick Time (GMT-7) Message
iaincollins 07:10 hi folks ...
Thanks for all the great work in Firebreath, very polished and easy to use
was wondering if anyone has thoughts on how best to handle plugin version upgrades, especially on Windows in particular (just due to it being more commonly used)
specificaly, without the browser having to be restarted (bit moon-on-a-stick request I know)
was thinking of putting a version number in the mime type and bumping it up with a new (but seeems kludgy)
or of just abstracting functions in the plugin to call other libraries (so I don't need to upgrade the plugin itself, just push out new libraries for it to call)
background: the sceanio is we can push new automated updates to users easily, but if a browser is loaded and has used the plugin cannot seem to uninstall/upgrade it unless they are closed and reopened. This is is not an reasonable limitation, but am just trying to come up with the best possible user experience (and with our use case, as simple as possible an experience is highly valueable)
*Oops, that should read: "This is not an unreasonable browser imposed limitation"
taxilian 08:10 iaincollins: I have some suggestions for you, but I am headed to class right now. I'll be back later
iaincollins 08:10 oh cool, thanks
taxilian 09:10 nirvdrum: so to confirm, you verified that it actually was scheduling on the main thread, right?
nirvdrum 09:10 taxilian: I gotta jet, but it looks like what's happening in the callback object is trying to be released from an ancillary thread.
callback.InvokeAsync executes on the main thread, as far as I can tell. The very first thing InvokeAsync does is schedule on the main thread.
taxilian 09:10 hmm. so you're saying that the NPObject gets released off the main thread, because the shared_ptr gets released last on a different thread
that makes sense
I'll have to think on that;
I will probably have to make it force that release call to happen on the main thread, which could be a performance concern :-/
nirvdrum 09:10 I need to dig in a bit more, but maybe I just bump the ref count on the main thread first.
Although, that'll likely leak.
When I get back today, I'll gist up the relevant portions of code and you can let me know if I'm just doing the callback stuff wrong, if you don't mind.
But, otherwise it actually works.
taxilian 09:10 the best way would be to not hold onto a shared_ptr on the secondary thread
but I'll add something to force it to call it on the main thread if you don't
nirvdrum 09:10 Well, how should I pass around the callback then (i.e, a JSObjectPtr)?
taxilian 09:10 yeah, I see your point. that's a very interesting problem that I haven't fully considered;
nirvdrum 09:10 Eh, like I said, I'll pastebin or gist it when I get back. I need to go give a pitch in a few min.
taxilian 09:10 ok
yeah, I'm in class reviewing for a test right now anyway
nirvdrum 09:10 Heh.
Pay attention!
taxilian 09:10 good idea
nirvdrum 09:10 Alright, I'm out for a bit. See you guys later.
taxilian 10:10 iaincollins: okay, I have a few minutes now; not a lot, but I should be able to give you some suggestions
iaincollins: let me know when you're back =]
iaincollins 10:10 oh hey there
any thoughts / advice appreciated, thought I would ask before I go re-inventing the wheel
taxilian 10:10 yeah
so there are some javascript functions hidden somewhere in the codebase
that might be helpful
from when I started building something for that
but then I ran out of time and haven't had any more since
but there are basically two ways to do it
you can either create a new mimetype and CLSID for each version
or you can be careful and a little creative with file names and install directories
iaincollins 10:10 cool, makes sense
oh interesting
taxilian 10:10 the way I've done it was with the second option
iaincollins 10:10 didn't think of the second option
taxilian 10:10 the trick is that different versions detect the plugin in different ways
but if you put each version in it's own directory and name the file in such a way that you can get the version out of the filename
then it works pretty well
basically you look at navigator.plugins["plugin name"].filename to get which version is installed
highly recommend using the WiX installer for installs
iaincollins 10:10 oh, that's handy info, I didn't release that was a property
taxilian 10:10 yeah
iaincollins 10:10 okay thanks, will think about that and give it a try
taxilian 10:10 as long as the mimetype, name, and description are the same, it should see only the newest version, but some versions of firefox work a little differently
iaincollins 10:10 ah I see
taxilian 10:10 this may also help:
iaincollins 10:10 thanks, that gives me something to try and check for
taxilian 10:10
iaincollins 10:10 oh great *saves&
taxilian 10:10 good luck, and consider contributing the code back to FireBreath so others don't have to reinvent the wheel =]
iaincollins 10:10 Yeah I'd really like to be able to do that :-)
We are thinking of a customer support tool (it's for - we do R&D stuff for TalkTalk (large UK based network provider))
taxilian 10:10 cool
iaincollins 10:10 so a simple upgrade path would be a nice thing to be able to achive as gives more flexiblity to roll out updates frequently :-)
taxilian 10:10 yeah; I have to warn you, though, that "simple", "upgrade", and "plugin" are rarely found in the same sentence
iaincollins 10:10 I can imagine :/
taxilian 10:10 you may want to consider using Google Omaha for your installs; that's probably the cleanest way that I've come across
iaincollins 10:10 I'll take a look at that
we actually have our own install process mechanism at the moment, for varing degrees of patching
taxilian 10:10 I will say this once again, though; if you are not using MSI installers, I *very very strongly* suggest that you do so for the plugin
iaincollins 10:10 that's always an idea of dubious merit (of course) but we've had pretty good QA resources and a nice testing community who help us
will definately consider that, at the moment we use MSI installers for the main app, but do have some out-of-installer based update paths
(which is not really ideal)
taxilian 10:10 the reason that I suggest MSI so strongly is that the #1 problem I have had with plugin installs is that over time, your process changes
and when that changes, you changes some of the details of how your plugin gets installed
iaincollins 10:10 I can imagine it's particularly messy with plugins
makes sense
taxilian 10:10 eventually, you have 5 different ways that your plugin could have been installed, and 1 or 2 that you don't realize are even possible due to problems with UAC and 64 bit windows, and then each installer is written to try to fix all of those problems
with MSI, it just removes the previously installed version; whatever was done is simply undone, even if it wasn't done the way you expected
and you move on
iaincollins 10:10 Hmm yes I can imagine, I see your point
taxilian 10:10 yeah; after a few executives of fortune 500 companies have problems with your plugin because it was installed on their computer as an administrator when you expect it to be installed as a normal user and the reg keys somehow got placed in the wrong place… well, your boss tends to not be real happy with things like that, and it doesn't matter if it wasn't your fault =]
there is just much much less to go wrong with an MSI
iaincollins 10:10 currently working on the installation process (as we *might* be wanting to optionally install a service as well) so will think on that
Yeah, had lots of fun reading up on best practice and handling odd situations like terminal clients, guest accounts, custom user-defined access controls levels on Vista with the current labs desktop client :-)
taxilian 10:10 hehe
iaincollins 10:10 Hmm, so will think about MSI then, and give directory + file naming some thought, thanks for that
taxilian 10:10 yw
oh, and along with the MSI; using an MSI is pointless if you have the DLL self-register (i.e. regsvr32 style)
iaincollins 10:10 Oh!
I'm glad you mentioned that :-)
Do you consider using regsvr32 "bad"?
taxilian 10:10 that's the reason that hte WiX stuff built into firebreath is so cool; it uses heat to generate an XML file that is imported by the main one in order to do the registration
for a real install, yes
regsvr32 is considered bad practice
the reason is that the install system doesn't know if the DLL properly registered everything
and the install system is much better able to ensure things get put in the right place — and removed again later
linked from that:
I should really create a wiki page about that
iaincollins 11:10 Oh, right then. I hadn't considered that. Was previously thinking of looking up API's to perform tasks equivolent to regsvr32
(as it's not something I've had to do previously, not had any exposure to it)
taxilian 11:10 yeah, I didn't learn that until I did the WiX installer, actually
it would have saved a lot of time if I had understood that previously
anyway, I need to finish math homework
good luck
iaincollins 11:10 thanks again! :)
taxilian 11:10 glad to help
iaincollins 11:10 I'll let you know how I get on... hopefully I'll have something by the end of the month, if no more sneaky urgent projects come up
from reading that sounds like WiX it is then
taxilian 11:10 well, if you use WiX you can either directly use the FireBreath stuff to make your installer or you can "borrow" some of the code to do your own
probably a lot easier
iaincollins 11:10 *nod* will definitely take a look at it
taxilian 11:10 these are the reasons why IMHO firebreath is a perfect fit for an open source project; the complexities apply to all plugins, and contributing code back doesn't give away any confidential IP
plus you get the benefit of anything you contribute back gets tested *a lot*
iaincollins 11:10 yeah, makes a lot of sense in this case
from what I've been reading, sounded like it was kicked off by interest from a commercial company?
taxilian 11:10 yeah, I was contracted to build a browser plugin framework
one of my stipulations in the contract was that I could release the framework as open source
iaincollins 11:10 I thought I'd read that
taxilian 11:10 ironically, the company who hired me originally never used it =]
iaincollins 11:10 aah cool I see
hah, was curious :-)
that's great
I've been trying to get some stuff released here (just so I can get some help with bug finding TBH ;-)
but management not super keen as people who have written worse versions have been trying to sell us crummy implimentations
just C# stuff, an none of it obfuscated (our or theirs) so it's easy to compare :-)
taxilian 11:10 hehe
iaincollins 11:10 (Decompiler actually makes some of my code *more* readable, which is slightly embarrasing)
taxilian 11:10 lol
iaincollins 12:10 time for home, more fun tomorrow!
kalev 12:10 taxilian: hey, I pushed a small changeset to dev which makes it possible to query plugin version with NP_GetPluginVersion()
a few days ago however I pushed some compiler warning fixes to stable; hope it doesn't mess up your merge workflow
taxilian 12:10 kalev: no worries, I saw your push
I would have said something if I were worried about it =]
kalev 12:10 great :)
by the way, I remember you talking about url parsing code
taxilian 12:10 anyone on the firebreath-scm mailing list gets an email whenever a push is made
kalev 12:10 no idea if it's of any use, but I have a small url parser too:
(probably nicer to do it with regex instead)
taxilian 12:10 actually, my personal feeling is that regex is overkill for this; why add a new dependency just for a simple text parsing?
kalev 12:10 true.
taxilian 12:10 I'll keep that in mind; Facebook's seems to work pretty well, but I'll compare them when I integrate it and try to take the best from both
time permitting
kalev 12:10 I'm just interested in having a way to get protocol (https) and hostname out of it
if that works I can scrap my own class.
taxilian 12:10 Facebook's has that
port as well, I believe
kalev 12:10 great
taxilian 12:10 'course, I'm not going to force anyone to use anything in specific
not for that
I still have to survive a math test, a algorithm programming assignment, and a 4 page paper about the aforementioned algorithm prog assignment; once I make it through all of that I can once again work on FireBreath stuff
kalev 12:10 hope you'll survive
taxilian 12:10 I'm sure I will, one way or another
I h ope I pass everything :-P
I do *not* want to repeat this
nirvdrum 15:10 taxilian: Did you have some time to run though that issue?
taxilian 15:10 sure didn't
what was the issue again? =]
oh, yeah
the mem free thing
nirvdrum 15:10 Sorry, do you have some time now?
I can gist up the code, unless you think you already understand the problem.
taxilian 15:10 not really; big test tomorrow, working on homework to prepare for it, another class starts in 10
but I can give you a suggestion
on how to fix it for now
nirvdrum 15:10 Sure. And no worries. You're certainly not obligated to help :-P
taxilian 15:10 well, it's a firebreath bug
basically you should have a browserhostptr, right?
so instead of calling host->releaseobject directly
use scheduleonmainthread to call
something like boost::bind(NpapiBrowserHost::ReleaseObject, host, obj)
rather host->ScheduleOnMainThread(host, boost::bind(....))
it doesn't matter that the release happens immediately
it matters that it happens soon
and in order
and on the main thread
that should ensure that
you could instead do it using callonmainthread, but that is a bit more of a performance hit
nirvdrum 15:10 Pulling up my VM right now.
taxilian 15:10 shutting down and going to class now =]
but I'll be back online when I get there
nirvdrum 15:10 Heh, okay.
See ya.
taxilian 16:10 back
nirvdrum: the place to modify is NPObjectAPI
really, IDispatchAPI should be updated as well
nirvdrum 16:10 Wow, you got there fast.
I'm trying one thing out. I'll be able to report back in about 10 min.
taxilian 16:10 well, I was just up 2 floors is all
nirvdrum 16:10 Okay. I thought it was my callback object being freed up that was the problem, but I just spawned a new thread and didn't pass the callback in, and I still ran into the memory access issue.
taxilian 16:10 what exactly are you seeing?
nirvdrum 16:10 An assertion error occur because an object is being freed from the wrong thread. But, I never explicitly call release, so I must be getting the reference counts screwed up someplace.
taxilian 16:10 yes
and no
the only time that a JSObject is freed is when the last reference to it is freed
nirvdrum 16:10 So, how should I be referencing my API class? Via shared_ptr now?
taxilian 16:10 yes
nirvdrum 16:10 Because I was just passing a MogotestPluginAPI* to the thread.
taxilian 16:10 JSObjectPtr is also a shared_ptr
yeah, don't do that
that could cause a real problem
and make sure you use the same shared_ptr that everything else is using
nirvdrum 16:10
Something like that.
captureEntirePageScreenshot is the method exposed to JS.
taxilian 16:10 right; so if you do that, most likely callback will get freed from the other thread
because it's a shared_ptr and you don't hold onto it anywhere else
so when it goes out of scope (your thread ends) it will get freed
nirvdrum 16:10 threadFunction is just a convenience to call back into the object from the other therad.
Okay. So, how do I pass a copy of "this"?
And apologies for asking all these boost pointer questions.
taxilian 16:10 instead of passing in "this", pass in "FB::ptr_cast<MogotestPluginAPI>(shared_ptr())"
nirvdrum 16:10 I'm used to old school pointers :-P
taxilian 16:10 no problem
I really need to clarify this on the wiki
'don't suppose you'd consider starting that project?
nirvdrum 16:10 Sure.
I'm going to need something to reference anyway :-P
taxilian 16:10 it would be really helpful =]
looks like you have access to the wiki already
nirvdrum 16:10 So, shared_ptr() packages up "this" in a shared pointer I take it?
taxilian 16:10 yeah
look at JSAPI.h
basically the object stores a weak_ptr to itself
that it can use to return a shared_ptr to itself
nirvdrum 16:10 AHh.
taxilian 16:10 but it returns a shared_ptr<JSAPI>, so you need to cast it to something else
yeah, it's very helpful for cases like this
nirvdrum 16:10 BTW, is there a wiki page on how this logger should be implemented?
taxilian 16:10 sure isn't =]
nirvdrum 16:10 It'd be nice to dump my custom one
taxilian 16:10 partially because that's not released yet
but I would be happy to tell you how to start using it
if you're willing to be a little patient and help me work out the bugs
nirvdrum 16:10 Sure. I'd imagine I just subclass what's there already and provide real implementations?
taxilian 16:10 not subclass; provide implementations
nirvdrum 16:10 Yeah, that's fine. I could even write an adapter into my existing logger to start.
taxilian 16:10 should be easy enough
currently it only works with log4cplus
but you should be able to copy what is there
you're on dev, right?
(well, actually, I'm about to push dev up to head, so it shouldn't matter)
by about to I mean in the next couple of days, as time allows
nirvdrum 16:10 Yeah, I am.
taxilian 16:10 look in PluginCommon
there is a NullLogger
and a Log4cplus Logger
log4cplus is used if the project is loaded
otherwise nulllogger is loaded
nirvdrum 16:10 Guess I need to update.
All I see is the null logger.
taxilian 16:10 right
you're only looking in the project, not on disk
nirvdrum 16:10 Ahh.
taxilian 16:10 look at CMakeLists.txt for that project
should help explain
nirvdrum 16:10 As a suggestion, name the first two args in logging.h. I had to look at the macros to figure out what they were supposed to be.
taxilian 16:10 do you mind naming them? I'll give you commit access =]
nirvdrum 16:10 Sure. I'll need to freshen up on mercurial though.
Before I break everything on everyone.
taxilian 16:10 main thing to remember: when you commit, unless you are specific on which files to commit (easy in tortoisehg), it will commit everything that has changed
so always do hg stat before you commit
nirvdrum 16:10 Heh, and I have barely a clue as to how to read cmake files. This project makes me feel borderline retarded at times :-P
taxilian 16:10 it's not as hard as it seems at first
nirvdrum 16:10 How does the log4cplus target get activated?
taxilian 16:10 in your PluginConfig.cmake put add_firebreath_library(log4cplus)
the idea is that other loggers could be added the same way
whichever one is added will be uses
or you can add your own in your own project
nirvdrum 16:10 Ahh. Well, that'll be good for the wiki, too.
taxilian 16:10 so "if (TARGET log4cplus)" block will be executed iff there is a target (add_library, add_executable) called log4cplus
right; it's another thing that is new in 1.3, though
you're on the bleeding edge =]
however, around here that is usually pretty stable anyway
nirvdrum 16:10 Gotcha.
taxilian 16:10 just usually not well documented :-P
nirvdrum 16:10 Heh, and that didn't fully take care of my pointer woes, so time to scrub the rest of the project.
taxilian 16:10 well, remember: the problem with it getting freed on the other thread is not something you've fixed yet
nirvdrum 16:10 Oh. I thought that was an artifact of me having screwed up the reference count.
taxilian 16:10 no, that's just something that could potentially cause a crash if your thread took long and the plugin got pulled
there are two ways you could fix this
you could fix it in FireBreath so that it will work this way (should be done anyway)
or you could update your plugin so that the API object holds a reference to "callback" (which is what is getting freed on the wrong thread) and your thread tells it to discard the reference when it is done
the problem is not with MogotestPluginAPI, the problem is with callback
nirvdrum 16:10 Hmm . . . I'll have to isolate this again to verify it is now the callback object that's a problem. I had some confounding issues going on here.
taxilian 16:10 trust me
nirvdrum 16:10 When I stopped passing callback around, I still had the problem.
taxilian 16:10 the issue you're having? can only happen on a JSObjectPtr
nirvdrum 16:10 Hmm.
taxilian 16:10 and specifically on a NPObjectAPIPtr, which is what it is on firefox
nirvdrum 16:10 This in Chrome.
*This is
taxilian 16:10 same thing
nirvdrum 16:10 Okay.
I'll defer to you.
taxilian 16:10 in this case, I mean "not IE"
the problem is that you aren't allowed to call any NPN_ functions from other threads
NPN_ReleaseObject (host->ReleaseObject) must be called to release the NPObject (javascript method) when your'e done with it
however, if the last shared_ptr reference goes away on the wrong thread… it will free the NPObjectAPI object and the destructor of that object will try to release it
thus you get the assertion failing
and believe me, Mozilla gets really cranky if you start violating those rules. I had them threaten to blacklist a plugin I worked on once for that
nirvdrum 16:10 Wow.
taxilian 16:10 yeah
that's why I have been meaning to put checks for this in for a long time
so the easiest way to fix this is just to change the destructor of NPObjectAPI so that it schedules the ReleaseObject to execute on the main thread
taxilian 17:10 crap. log4cplus does not compile nicely (yet, anyway) on mac
at least using cmake
nirvdrum 17:10 Alright. I feel better having now proven I'm down to just the callback issue.
taxilian 17:10 always good to know =]
general rule of thumb: if you are using a normal pointer to refer to a firebreath object, you probably shouldn't be
nirvdrum 17:10 Heh.
cygmatic 17:10 i'd even make this a C++ rule of thumb ;)
taxilian 17:10 that might well be :-P
nirvdrum 17:10 Well, Firebreath still does some of that. E.g., GetWindow() returns FB::PluginWindow*
taxilian 17:10 yeah; that's one of few exceptions
getPlugin also gets a PluginCore*, but I'm really considering changing that
mainly I'm not because I don't want to break one more backwards compatibility
nirvdrum 17:10 Yeah. All of this plugin was written back when dumb pointers were king in the project.
So, PluginCore references should not use smart pointers?
taxilian 17:10 references in the API?
if you need to reference your PluginCore object from your API, you should keep a boost::weak_ptr to it
nirvdrum 17:10 Within my app. I hand a reference to the plugin object over to the API one so I can grab the window.
taxilian 17:10 yeah, use a weak_ptr
nirvdrum 17:10 Alright, I'll do that.
taxilian 17:10 you can get the shared_ptr for the plugincore objet with shared_ptr() just like in an API object
when you need to use it, you call w_ptr.lock() and that will return a shared_ptr object
that will keep it from getting freed until the shared_ptr goes away
nirvdrum 17:10 Well, IIRC there was some weird lifecycle stuff with the plugin and api objects. So, I didn't want to screw up reference counts.
taxilian 17:10 don't keep the shared_ptr longer than a function call, though, because otherwise you have a recursive reference and thus a memory leak
right; that's why you use weak_ptr
nirvdrum 17:10 Gotcha.
Fun stuff.
taxilian 17:10 that is also new in 1.3
very nice trick =]
cygmatic 17:10 by the way, one of these days someone(tm) should write a "what to watch out for when writing mac plugins" article
taxilian 17:10 yeah
that would be good
cygmatic 17:10 i just updated one that only worked on windows (without firebreath) and realized how much i already forgot again
... and realized how annoying it is to not have all those browser and platform differences abstracted away ;)
taxilian 17:10 lol
now you remember why we're doing this?
cygmatic 17:10 you only realize what you have if you don't ^^
weird sentence, but i hope you know what i mean
taxilian 17:10 made sense to me
cygmatic 17:10 also btw, i don't think i'll be getting anywhere this week with the timers
have some kind of architectural chicken & egg problem with them
taxilian 17:10 ok; I'm a bit behind where I wanted to be for 1.3 also
and we may need to push timers to 1.4
cygmatic 17:10 seems like users would like it though :/
taxilian 17:10 oh, I'm sure they would
have you looked at the survey lately? we're up to 26 responses, I think
cygmatic 17:10 just looking :)
love the comment on #20
nirvdrum 17:10 taxilian: Just to make sure I understand correctly, I'd call .lock() on the weak_ptr to do any real operations?
taxilian 17:10 something like:
shared_ptr<PluginObject> obj(weakptr.lock());
then when obj goes out of scope it will be unlocked
preferably even have a function like getPlugin() that returns weakptr.lock()
and checks to see if the result is null and if so throws a script_error
because that means the plugin object has already flown
nirvdrum 17:10 Well, I just want to call a method on what was previously a simple pointer but is now a weak_ptr.
cygmatic 17:10 or even: if (shared_ptr<X> sp = weakptr.lock()) { /* ... do stuff */ }
nirvdrum 17:10 Do I need to wrap in a shared_ptr?
Or is calling lock() sufficient?
taxilian 17:10 that's what .lock does; it returns a shared_ptr
cygmatic 17:10 the resulting shared_ptr should be checked
nirvdrum 17:10 Ahh, gotcha.
cygmatic: If it fails, there's no reasonable course of action I could take anyway.
Other than log and move on.
taxilian 17:10 you really should have something checking to see if lock() returns an empty shared_ptr
nirvdrum: if it fails, then you should just do nothing
the alternative is that you could crash
if you don't check
cygmatic 17:10 nirvdrum: just saying you can't do "shared_ptr x = weak.lock(); x->foo();" and think it always works
nirvdrum 17:10 taxilian: Both are the same outcome. I didn't get what I needed.
A plugin that no-ops is no better than one that crashes.
cygmatic: Fair enough.
taxilian 17:10 nirvdrum: the only reason that would happen is that your plugin was removed from the DOM
and the browser released it
nirvdrum 17:10 taxilian: Now, is there anything cool that gives me a weak_ptr from the current plugin? Or is this all boost?
I'm still working out when there are helpers available and when I'm on my own :-)
cygmatic 17:10 taxilian: wow, how did the FBTestPlugin release build jump to 1.4mb on mac?
taxilian 17:10 cygmatic: the *build* jumped to 1.4? wow
the only thing I can think of is the new boost stuff and threading; would not have expected that to make it that much bigger, though
is that release as well or just debug?
cygmatic 17:10 release, debug is a bit bigger
taxilian 17:10 huh
cygmatic 18:10 ok, at some point binary size profiling should be done
taxilian 18:10 agreed
nirvdrum: I thought I had an example, but it isn't hard
you create a boost::weak_ptr from a boost::shared_ptr
nirvdrum 18:10 Okay. I'll google for that.
taxilian 18:10 so basically in your constructor for your API object, just add boost::shared_ptr<YourPlugin> & and store it in your boost::weak_ptr<YourPlugin> in that class
nirvdrum 18:10 Looks like I can't set things to NULL anymore either. cygmatic must be thrilled :-P
taxilian 18:10 then I recommend adding a boost::shared_ptr<YourPlugin> getPlugin() { } method
which things?
nirvdrum 18:10 onWindowAttach I used to do api->setPlugin(this). onWindowDetatched: api->setPlugin(NULL)
taxilian 18:10 you don't need to do that anymore
nirvdrum 18:10 Trying to clean that up into all this weak_ptr stuff.
cygmatic 18:10 nirvdrum: what, why? did i do something? ^^
taxilian 18:10 just setPlugin(shared_ptr()) instead
and store that in a boost::weak_ptr
nirvdrum 18:10 Oh? The assignment operator is overloaded for that?
taxilian 18:10 when it is locked (when you have a shared_ptr from the weak_ptr) the plugin can't get removed
you can assign a shared_ptr to a weak_ptr
nirvdrum 18:10 cygmatic: You seem to be the resident proponent for me not using raw pointers :-)
Good to know.
cygmatic 18:10 nirvdrum: ah, yes i can be vocal about such matters... but only because it greatly reduces error sources :)
taxilian 18:10 nirvdrum: trust me, this greatly reduces the number of potential crashes
and it is actually easier
nirvdrum 18:10 My smart pointer experience is limited to whatever MS provides and/or what I've rolled on my own. boost seems to have like a half dozen of these things all with nuanced semantics.
cygmatic 18:10 taxilian: so when do you think should we distill the essence from that survey?
taxilian 18:10 cygmatic: I'm thinking we should probably do it soonish, but put up another ongoing one
it has been very helpful
cygmatic 18:10 nirvdrum: shared_ptr, weak_ptr & unique_ptr are the 3 that are de-facto standards (and will be in the next C++ standard) - the rest are "special use-cases" or convenience
taxilian 18:10 cygmatic: what is unique_ptr?
cygmatic 18:10 taxilian: basically single ownership without the fatalities of auto_ptr
taxilian 18:10 ahh
cygmatic 18:10 taxilian: so you're going to write a summary for the survey to fb-dev at some point?
taxilian 18:10 yeah, probably so
cygmatic 18:10 sounds good, tell me if you need any input :)
taxilian 18:10 mainly what I lack right now is time
as usual
cygmatic 18:10 where did i hear that before? ^^
i'll try to get to the timers... if i can spare any time i'll try to get onto the media player on mac
a x11 version from me is unlikely though
taxilian 18:10 yeah, understood
nirvdrum 18:10 So, as expected, keeping a reference to the callback around in my API object fixes that issue.
taxilian 18:10 yep
nirvdrum 18:10 Now, to track down why Chrome seems to be giving me a junk HWND.
taxilian 18:10 yeah, that does sound a little weird
nirvdrum 18:10 Am I just using Firebreath really wrong? I seem to run into a whole bunch of issues others don't.
Although I'm pretty sure amackera_away reported this one, too.
taxilian 18:10 no, I think most firebreath users just don't use any drawing
and don't do anything as advanced as what you're doing
and/or don't bother asking for help
also, you are one of the first that I know of to update from 1.1 to 1.2 and later
nirvdrum 18:10 Ahh. Well, I think I'm running well on 1.3-dev now.
I feel better about that.
So, thanks a ton for the help there.
taxilian 18:10 no problem
it's a good place to be running on, really
nirvdrum 18:10 If you have a favorite bottle of something, let me know and I'll send one out :-)
taxilian 18:10 lol
nirvdrum 18:10 I'm serious.
taxilian 18:10 root beer is good :-P
nirvdrum 18:10 It's the least I can do.
taxilian 18:10 but I'd rather just have a little help on documentation and wherever you can
nirvdrum 18:10 For root beer I'll just paypal you the $5 :-P
taxilian 18:10 hehe =]
nirvdrum 18:10 I'll try to slap something together.
taxilian 18:10 just keep using FireBreath and helping us find issues; that's actually a lot of help
nirvdrum 18:10 Worst than writing the actual docs is putting up with gcode's interface.
taxilian 18:10 and anything you can help with on documenting these things
nirvdrum 18:10 It is truly one of the worst products I've ever used.
taxilian 18:10 tell you what; if you write the docs and send them to me, I'll format them for gcode and put them up =]
nirvdrum 18:10 Heh. I'll suck it up. Don't worry.
taxilian 18:10 I've considered moving firebreath's docs to another server; I actually have a server I could put it on
and I have some plans for things to put there
we even own
but I don't know of another wiki that is good enough to be worth the trouble
nirvdrum 18:10 I'm a huge fan of Confluence. But, it requires a fairly beefy server to get going.
It's one of the few wikis intuitive enough that I've been able to throw non-techies at and have them actually understand how to use it.
taxilian 18:10 isn't that a pay one?
(I have the beefy server, actually; particularly if I can get some "value-add" stuff up for those willing to donate to support the cost of the server)
nirvdrum 18:10 They do free licenses for open source projects.
taxilian 18:10 oh, really? I did not know that
nirvdrum 18:10 Otherwise, they have a 10 user license for $10.
taxilian 18:10 I might have to look at it, then
nirvdrum 18:10 If you have more than 10 people contributing docs, you're doing well.
Alright. My wife is informing me dinner is ready. I'll be back in a bit.
taxilian 18:10 true =] but I'd really like something that almost anyone can contribute, with some moderation capabilities
nirvdrum 18:10 But, you really should study for that test :-)
taxilian 18:10 oh, I'm in another class right now :-P
hurray, I got log4cplus building on mac!
with cmake
cygmatic 18:10 yay
is it really that painful?
taxilian 18:10 cygmatic: it was using autoconf's platform detection stuff for "HAS_PTHREAD", "HAS_"… lots of stuff
it came with a CMakeLists.txt that worked perfectly on windows
but didn't on mac/linux
just about have it all fixed, though
cygmatic 18:10 oh, that sounds like "fun"
taxilian 18:10 err, yeha
I have learned a bit, though =]
just need to get unicode support working on it, and I can push the fix up to dev
taxilian 19:10 excelent; it builds on all platforms
hopefully that means it works on all platforms too :-P
nirvdrum 19:10 taxilian: Are you sure I have wiki access? I can't see any links that would allow me to edit pages.
taxilian 19:10 either remove ?tm=6 from the url or click on "this list of all wiki pages"
nirvdrum 19:10 Ahh.
taxilian 19:10 yeah, kinda weird
I may very well look into that other wiki you mentioned. what does it run on? Java?
nirvdrum 19:10 Yeah.
taxilian 19:10 it doesn't have a built-in issue system, does it?
nirvdrum 19:10 Integrates with about every DB you could think of.
No. JIRA is their issue tracker.
I'm also very fond of that. But it's not for everyone.
taxilian 19:10 does JIRA also have an open source free license, by chance?
I've used JIRA; it's okay
nirvdrum 19:10 Indeed.
taxilian 19:10 hmm
very interesting
nirvdrum 19:10 Pretty much anything Atlassian does has a free license for open source projects.
taxilian 19:10 I will speak to some of my co-conspirators about this
nirvdrum 19:10 You need to apply for it, but they really just verify you're a bona fide project and not just trying to scam them.
taxilian 19:10 I think FireBreath can probably pass that test
cygmatic 19:10 i don't know much commercial trackers besides jira, but have the feeling there has to be one with a less cluttered interface
nirvdrum 19:10 So, you could get free Bamboo licenses too, if you think that'd work out as your CI server.
taxilian 19:10 well, for now Hudson works fine, but we could look at it
nirvdrum 19:10 cygmatic: I'd rather take the cluttered ones that let me actually do something over the ridiculously simplistic ones, like GitHub and Lighthouse provide.
But again, to each his own.
I think we can all agree Bugzilla is a steaming pile of shit though.
taxilian 19:10 cygmatic: JIRA interface is pretty customizable, so you can unclutter it
nirvdrum: no arguments here on that score
nirvdrum 19:10 They cleaned up a lot for 4.1. 4.2 is supposed to be simpler. But, i mostly use the GreenHopper agile interface anyway *shrug*
cygmatic 19:10 nirvdrum, good point... still a bit more optimized ui would be nice
taxilian 19:10 if someone wants to find me more info, I might be persuaded to go to something about that
cygmatic 19:10 funny, i can't find a neat graphical tool for gcc map file analysis
nirvdrum 20:10 cygmatic: valgrind doesn't help out there?
taxilian: I did a fair bit of research into the wiki & issue tracking space about a year back. I settled in on JIRA & Confluence. Redmine is a nice free alternative. Retrospectiva looked interesting as well, but I had already made my decision by the time I came across that.
cygmatic 20:10 nirvdrum: the idea would be to have a graphical or textual representation of what contributes to FBs binary size, ordered by size per modules and symbol... i have no idea if valgrind can help there
nirvdrum 20:10 cygmatic: Nor do I. I'm speaking about things in which I'm not very knowledgeable.
cygmatic 20:10 its strange... somebody must have written some script or utility... but my search doesn't turn up anything :/
taxilian 20:10 cygmatic: have you seen this?
this for windows:
might be something useful here as well, not sure:
cygmatic 20:10 taxilian: yeah, both not really, especially with the "order by size" flag missing on osx. the SO one turns up nice artwork though:
taxilian 20:10 interesting
my thinking is that we may be running into cases where our templates are expanding nearly out of hand :-/
we do have a lot of templated code
cygmatic 20:10 but most of my templates are for JSAPIAuto, which shouldn't contribute too much for the test plugin
taxilian 20:10 there are also boost things getting used for a lot right now
the scheduleonmainthread and callonmainthread stuff
boost::shared_ptr all over the place
might not be that much, but might
I don't know
just a theory
cygmatic 20:10 hm, hard to say without numbers
taxilian 20:10 right
cygmatic 20:10 i could hack something up WhenIHaveTime(tm)
taxilian 20:10 I'd bet that the visual studio version is about the same; you could try this:
cygmatic 20:10 yeah, maybe looking into it on windows first is better
there are some tools i know of
well, not today
good night
taxilian 20:10 sleep well and wake
nirvdrum 20:10 Well, that's spectacular. I'm getting a good HWND after all, but getting a junk "width" value.
taxilian 20:10 on windows I wouldn't trust the browser to give you good width info
query the HWND to get that
nirvdrum 20:10 Well, I ask the DOM what it thinks the width and height should be and then I set the window to those dimensions.
I guess I could try to figure it out based upon the scrollable regions, but it's not exactly the same thing.
Weird that the value comes back as "undefined" for only a handful of these URLs.
taxilian 20:10 is this the browser window or your plugin window?
nirvdrum 20:10 Of course the value can't be cast to int, so I get a cast error.
It should be the containing document.
taxilian 20:10 ok
nirvdrum 20:10 document.documentElement.scrollWidth & scrollHeight give me what I want.
taxilian 20:10 some browsers report that differently; you may need to query something other than just width
something like that