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

IRC Nick Time (GMT-7) Message
leosamu 03:10 hi there
leosamu 03:10 i have a doubt about firebreath and external dependencies
cygmatic 03:10 hi
what exactly is the problem?
leosamu 03:10 hi
im an University student developing a firefox plugin that uses OpensceneGraph to render 3D
but when i moved to linux i noticed that firefox doesnt load the external libraries
so i decided to use firebreath hoping there is a way to solve it that isnt related to a static compile of OSG libraries
cygmatic 03:10 are the OSG libraries somewhere where they can be found?
i.e. can you put a simple test program that links to them into arbitrary locations and it loads them?
leosamu 03:10
i can make an example of a plugin that might load them
cygmatic 03:10 i mean do you have the OSG libraries installed so that the loader can find them?
leosamu 03:10 i have osg libraries installed
cygmatic 03:10 a browser plugin shouldn't really be different in that regard
leosamu 03:10 my problem is that i want to make an xpi that includes the plugin and OSG so people who wants to use it doesnt need to install latest version of osg
windows was smooth since i just put external libraries on the same directory as the plugin
cygmatic 03:10 so the osg libraries are installed in the same location as the plugin?
leosamu 03:10 thats what im triying to
but the plugin on load doesnt loads the external libraries
cygmatic 03:10 i haven't tried that on linux, but you may have to use chrpath in that case
on osx you'd use install_name_tool to make the embedded path to the lib relative to @loader_path
on linux i think "rpath -r [something?]" is it
leosamu 03:10 ok
ill try it
thank you
cygmatic 03:10 *chrpath of course
you're welcome
cygmatic 04:10 hm, there is $ORIGIN but that seems to be only relative to the executable, not the library (i.e. the plugin)
leosamu: some other post says $ORIGIN works for .so too, so give it a try:
leosamu 04:10 oh
i guess that thats what i was searching for
cygmatic 04:10 let me know if that works and i'll add it to the documentation
leosamu 04:10 ok
im checking this
if works ill tell youç
cygmatic 04:10 great, good luck :)
taxilian 08:10 cygmatic: I think it definitely makes sense to add addEventListener to FB::DOM::Node, but it's going to be a bit tricky since IE works a bit differently
cygmatic 08:10 FF didn't like it either
some funny xpcom error
taxilian 09:10 leosamu: creating an XPI with binaries on linux is a really rough proposition.
XPCOM error? really? weird...
leosamu 09:10 hi
taxilian 09:10 howdy
leosamu 09:10 i tested the chrpath but if i make it with relative path
it becomes relative to the executable
not the library
so im still searching
taxilian 09:10 the problem with prepackaged binaries on linux is that every linux distribution has slightly different versions of each shared library, including glibc
most likely it won't work on most of them
leosamu: the main trick with what you're doing is probably going to be that it isn't your plugin .so that is loading the shared library; it's the firefox (or whichever) executable
leosamu 09:10 i tested launching ff on console on the same path as the .so and on diferent paths
cygmatic 09:10 yep, and i can't find an equivalent to osx' @loader_path
leosamu 09:10 same here
i dont want to use a static compilation but seems i have to
so sad
i wanted something like @loader_path
taxilian 09:10 leosamu: dynamic linking from a browser plugin is a pain ;-/
I bet there is a way to do it, though
cygmatic 09:10 i'd try stackoverflow on "how to link to shared lib from shared lib with relative path"
(without setting enviroment variables)
leosamu 09:10 moonlight proyect does it using mono libraries
taxilian 09:10 must be a way, then
leosamu 09:10 and i tried a stubloader but its buggy
as @taxilian stated is a pain
if i find a way to solve it ill tell you here
cygmatic 09:10 try and give us a link so we can vote/favorite it... worst case scenario is you don't get any helpful answers :)
leosamu 09:10 ok
and ty
leosamu 09:10 posted there
taxilian 09:10 leosamu: link?
leosamu 09:10
taxilian 09:10 cygmatic: (and anyone else who wants to weigh in) I think I have a way to do some automated-ish mojo to put the class docs into confluence; should we put it in a seperate space, which would have the side effect of losing the common side nav that the rest of the site has, or do I put it in essentially where it is?
cygmatic 09:10 taxilian: cool, how about testing it in a separate space and moving it over if it doesn't break? :)
leosamu 09:10 testing stuff on a test server is a nice idea
taxilian 09:10 lol. cygmatic: you're so picky :-P
I will of course at least do that
just wondering where you think it should eventually go =]
cygmatic 09:10 ah, well... somebody has to play the picky role ^^
taxilian 09:10 and to be fair, you're very good at it, and the project is better because of it =]
speaking of which, I agree with your comments on the logging stuff
do you want to make the fix or should I?
cygmatic 09:10 yeah, integrating in the main space would of course be great
taxilian 09:10 ok
cygmatic 09:10 go ahead if you're at it anyway
taxilian 09:10 I'm not, but I can sometime probably today
not totally sure I know how to do it properly (I've never used anonymous namespacing)
but I guess static would work; I'd forgotten about that
I think I'm going to try to get JSAPISecure written, and then start looking at releasing 1.3 this week
cygmatic 09:10 namespace { define_stuff() { ... } } is all there is to it
it's equivalent to: namespace SomeUniqueName { /* stuff */ } using SomeUniqueName;
taxilian 09:10 ok
and then you can access any of that stuff only in the local file?
local scop
cygmatic 09:10 only in the file that sees the unnamed namespace, because the unique name is never known to the developer
taxilian 09:10 ahh
fair enough
cygmatic 09:10 while i'm looking at the logging and in a picky mood... shouldn't the logging macros be no-ops unless some FB_USE_LOGGING is enabled?
taxilian 09:10 that's into parts that I haven't made firm decisions yet
cygmatic 09:10 and wouldn't it be nicer to have no-oppable streaming macros like FB_LOG_TRACE("moo", "hi " << name "!");
taxilian 09:10 should it default on or off?
I don't know how to do that :-/
cygmatic 09:10 no idea, but i'd like to be able to turn it off :)
taxilian 09:10 absolutely
that is definitely needed
so my thinking was that if we use std::string as the param type, it's less likely to optimize out the function call if the function call doesn't do anything
but I'm not certain if that is true or not
but that's why I used const char* instead of std::string for the params
cygmatic 09:10 shall i make it FB_DISABLE_LOGGING and the default behaviour doesn't change for now?
i don't think that really matters here
taxilian 09:10 I'm really of two minds
tell you what; do whatever you think makes the most sense with logging and I'll tweak it next
we'll go back and forth a few times and come up with something we both like =]
cygmatic 09:10 fair enough ^^
taxilian 09:10 I'm definitely open to having better macros; mostly I was trying to keep the implementation needed to add a new logger simple
the idea being that what we need for the core is fairly minimal, and then they can implement whatever they want for their own stuff
but I haven't plumbed in everything to make it so you can add your own logger :-/
cygmatic 09:10 __FUNCTION__ would be nice to have too?
cygmatic 10:10 leosamu: do you mind if i clarify your question on SO a bit?
hm, did it - roll back if you don't like it :)
taxilian 10:10 cygmatic: that would probably also be nice to have
though I'm not yet using it for anything
cygmatic 10:10 taxilian: do i have to define LOG_FILE myself when building?
taxilian 10:10 cygmatic: at present, I haven't actually really used file logging
what we really should do is define some sensible defaults
but PluginCommon is project specific
so you should be able to put something in PluginConfig
cygmatic 10:10 default probably off... and FB_USE_LOGGING set to 1 or 0 like the Mac window stuff?
taxilian 10:10 yeah, definitely be consistent
problem is FB_USE_LOGGING will have to be more global
since logging is used in ScriptingCore and PluginCore
cygmatic 10:10 well, i have made the macros no-oppable
taxilian 10:10 ok; I'll wait and see what you come up with
did you see how I have it set to decide which logger to use so far?
we'll need a way to specify that the user is going to provide their own as well
and I appreciate you looking at this; I got kinda burned out on it
but I'd really like to have it in for 1.3
cygmatic 10:10 with the add_firebreath_library(), yeah :)
taxilian 10:10 well, and in PluginCommon checking to see if log4cplus has been included
cygmatic 10:10 hm, i'll guess i have to put it in a clone first to check at least on windows
cygmatic 11:10 taxilian: what do i need to do so i can include config?
i don't see why it works in the pluginwindow projects but not in plugincore
taxilian 11:10 because pluginwindow is project specific
plugincore is not
so if you have multiple plugin projects, you don't know which config to include
cygmatic 11:10 ah, damn it
so we still have to go with a global switch and default logging macros on
taxilian 11:10 YEAH
thisisbasil 11:10 is anyone here?
taxilian 11:10 I keep going back to the possibility of making it so that everything is just dependent on one plugin, like some have requested, but that is even further from the other goal of keeping as much as possible so that it can go into a shared library
yeah, we're here =]
thisisbasil 11:10 ok, this might be trivial here
cygmatic 11:10 hi thisisbasil
thisisbasil 11:10 hello all
taxilian 11:10 this is a happenin' place
there is almost always someone here
thisisbasil 11:10 is there a particular reason why i cannot create a method with simple types
i.e. int, bool
taxilian 11:10 and questions ask when we're away get answered when we get back, if you stick around long enough
what version are you using?
thisisbasil 11:10 the daily build from friday
taxilian 11:10 this is in a JSAPIAuto derived class?
thisisbasil 11:10 yes
taxilian 11:10 can you pastebin the method signature and how you're trying to register it?
because you shoudl be able to just fine.
thisisbasil 11:10 void setOptions(int isRec, int isCase, int isBin);
and in the constructor:
registerMethod("setOptions", make_method(this, &BrowserAPI::setOptions));
taxilian 11:10 and what are you seeing?
cygmatic 11:10 this looks just fine - does it fail to compile or only when calling it? does the FBTestPlugin build and work fine?
thisisbasil 11:10 it wont compile
1 second, will get the error msg
taxilian 11:10 pastebin it if it is larger than 1 line, please
thisisbasil 11:10 im not familiar with pastebin, how do i do that
taxilian 11:10
thisisbasil 11:10
sorry for the delay
had to speak with my project mgr real quick
taxilian 11:10 the url you should have sent was
just FYI
thisisbasil 11:10
taxilian 11:10 cygmatic: I thought you removed the check not allowing int in favor of boost::dynamic_cast?
numeric_cast, that is
thisisbasil 11:10 apparently not
taxilian 11:10 thisisbasil: in the mean time, change int to long and see if it works
bool should work fine, though
thisisbasil 11:10 yes it works with long
taxilian 11:10 ok; that's been the case in previous versions, but I thought we'd changed it. perhaps it was a miscommunication. use that for now, and we'll discuss it
thisisbasil 11:10 alright
thank you for you help
have a good one
cygmatic 11:10 maybe only on dev?
taxilian 11:10 I pushed dev to stable several days ago
cygmatic 11:10 let me test after i checked the logging stuff on linux
taxilian 11:10 ok
cygmatic 12:10 hm, it is indeed still in there... strange :/
it amazes me though that nobody seems to read the big fat comment
taxilian 12:10 lol
well, after 1.3 they won't have to
and little exceptions will be thrown if they should have
and thus it becomes someone else's problem, and I am content =]
cygmatic 12:10 "why does my plugin crash with some weird exception when using some simple types?" ;)
taxilian 12:10 lol
the plugin shouldn't crash, though
it should just throw funny exceptions into javascript
cygmatic 12:10 right, thats a bit better ^^
taxilian 12:10 hey, if they know anything about javascript that should be enough
cygmatic 12:10 so, logging is pushed, you can start reverting my changes ;)
taxilian 12:10 lol
in a completely unnecesary attempt to prove my insanity beyond a doubt, I'm writing a python script to import all of the doxygen docs into confluence
so I'll look at it when I either finish it or get so frustrated with working with it that I quit
cygmatic 12:10 woah, i'm curious of the outcome
taxilian 12:10 It's going to require a little creativity
but I think it'll work pretty well
we'll see =]
cygmatic 12:10 are you going with xml transforming or html include hackery now?
taxilian 12:10 html include hackery
but I'm using xml to determine what I need to rewrite in the html files
so that they will link to each other nicely
this might not neccesarily run "fast"
but it shouldn't matter, if I write it correctly
it will first generate the doxygen files, next create a second directory for use in confluence, and finally add/update/remove confluence pages that will html_include the modified files
cygmatic 12:10 sounds good, props for taking the time
taxilian 12:10 I really shouldn't
I don't actually have the time
but this will be really nice when it is done
and I think we may actually have people go from thinking our docs suck to thinking they are fairly servicable =]
cygmatic 12:10 i know the feeling - i guess i shouldn't have read through the logging stuff today ;)
and yes, those integrated class docs will be great
its much more accessible than hopping through the source
taxilian 12:10 no kidding
and while having it on a seperate site is okay, this will be much better
cygmatic 12:10 started
hopefully we can update it with linux info at some point
and i should link to the CMake library linking stuff there
taxilian 12:10 you can actually do some of that with cmake directly
but yeah, that's a good idea
we should add some pages on how to add include dirs and link libraries
I guess link libraries should go there
cygmatic 12:10 i don't know what of that i can do with CMake - but then it doesn't hurt to have it both ways (for post-build scripts integrating the stuff etc.)
taxilian 12:10 true
towards the bottom there is some info that is partially relevant to that
there were some other things that I figured out once but can't remember specifics now having to do with the loader path
cygmatic 12:10 phew, i won't dig through that today
or anytime as long as i don't actually need it myself
taxilian 12:10 lol
cygmatic 12:10 to what variable should a plugin writer actually add the libraries and includes?
taxilian 12:10 no variable; just add them to target_link_libraries(${PROJNAME} ...)
or to include_directories( … )
cygmatic 12:10 ah, right
taxilian 12:10 either in CMakeLists.txt or projectDef.cmake
depending on whether it is project specific or not
cygmatic 12:10 i was looking at the plugin writers view
so PluginConfig.cmake or CMakeLists.txt?
taxilian 12:10 no
PluginConfig.cmake I guess would work for include_directories
but a better place for include_directories is CMakeLists.txt if it is global to their plugin (all platforms)
and <platform>/projectDef.cmake if it is platform specific
cygmatic 12:10 ah
taxilian 12:10 and I'm going to declare the new wiki a resounding success; if only because it's got all of us writing docs again :-P
cygmatic 12:10 somehow it is easier to see the holes now :/
taxilian 12:10 yeah; the improvements of the new wiki aren't neccesarily glaring. Seems like we should have been able to do all of this before
but not it's somehow easier
I call that a good change
brb, gotta go down to class
cygmatic 13:10 take a quick look if you can, then i'm off for today:
taxilian 13:10 looks good so far
cygmatic 13:10 (from doing stuff at least, there is always time to be picky though)
taxilian 13:10 yeah; I will probably be picky when it is more fleshed out
for now it looks good
amackera 13:10 aw, windowless plugins get coordinates relative to the browser's window
i guess i can translate it since we have clipping rect from SetWindow
taxilian 13:10 that seems like the sort of thing that ought to be done; it would also be cool for the window to be able to translate cooridnates from screen coordinates to plugin coordinates at any time, if that is even possible
amackera 13:10 it's possible, absolutely
do you mean have a utility function that plugins can call to translate coordinate spaces?
taxilian 13:10 yes
I think that would be very handyish
amackera 13:10 yeah that makes sense
kylehuff 13:10 with a "windowless plugin", does that remove the need for gtk/Coccoa/etc, etc.. ?
taxilian 13:10 the guys who wrote the Silverlight plugin were trying to convince me it couldn't be done on Mac at one point
amackera 13:10 kylehuff: no, it doesn't
taxilian 13:10 kylehuff: not really… but non-drawing plugin support is on the list
I'm actually thinking that it will go in with windowless, though
amackera 13:10 taxilian: they were trying to tell you that screen<->plugin coordinate mapping was impossible on mac?
taxilian 13:10 because if we're not going to draw, it seems like it would be better to have a non-drawing windowless than non-drawing windowed
amackera 13:10 taxilian: firebreath already does this
taxilian 13:10 amackera: and since they'd just explained to me how a pure virtual function works in C++ I wasn't really in a position to argue with them at the time
this was a few months before they released Silverlight 2
kylehuff 13:10 that is what I am looking for, non-drawing, windowed or windowless makes no difference to me.
amackera 13:10 kylehuff: yeah that's slightly different
taxilian 13:10 kylehuff:
amackera 13:10 windowless really only means the plugin doesn't have it's own special OS window (in windows that's an HWND)
taxilian 13:10 it's going to be pushed to 1.4, unfortunately
amackera 13:10 is that blocked on me? i remember you wanted a no carbon/cocoa/etc. for mac
taxilian 13:10 amackera: it's blocked on two things; that's one of htem
the other is windowless plugins in general
so yeah, I guess you could say that. :-P
amackera 13:10 lol
taxilian 13:10 well, and we need to write the actual code to have a FB_DISABLE_DRAWING or something like that
that defaults to false
amackera 13:10 right
taxilian 13:10 but if true removes the dependency on cocoa, carbon, gtk, etc
amackera 13:10 why do we need to do this? for non-drawing plugins to have a smaller binary size?
taxilian 13:10 no
that will get optimized out
it's just to reduce the number of dependencies
primarily on linux, since on mac and windows they are there anywya
amackera 13:10 i see
cygmatic 13:10 well, no carbon eases the 64bit <-> 32bit mess
kylehuff 13:10 for me, it would help with building - I won't need gtk-dev on my build system
taxilian 13:10 however, it seems like making them windowless would be a good idea along with that
amackera 13:10 is there a window/windowless distinction on linux? i am completely ignorant about the X11 side of NPAPI
taxilian 13:10 yes
amackera 15:10 awww, no WM_CHAR message for windowless plugins!?
taxilian 15:10 what is WM_CHAR?
amackera 15:10 it's a WM_KEYDOWN that's already been run through TranslateMessage
taxilian 15:10 interesting
doxygen generates some nice charst
amackera 15:10 cool!
taxilian 15:10 I just ran a command that automatically created confluence pages for each class in my doxygen root =]
progress is being made
and this is pretty cool
amackera 15:10 :D
taxilian 16:10 still early stages, but promising:
taxilian 18:10 cygmatic: when you get back, take a look:
I'll probably move that to the main area a little later today
cygmatic 19:10 taxilian: great, looks good :)
namespace DOM looks broken though
taxilian 20:10 cygmatic: that's the docks that are broken, not the doxygen integration
taxilian 20:10 cygmatic: the docs are now on the main site
the root pages under Source Documentation, including Source Documentation itself, can be modified
the other files if you modify will get changed back