IRC Log Viewer » #firebreath » 2010-12-15

IRC Nick Time (GMT-7) Message
Taleb 02:12 Hello, I have a question:
i run after installing Wix-3.5 the command: prep2010 examples buildex
Than, in Visual Studio 2010, I run 'Build Solution'
in the projects, I didn't find any WixProject and in the output build, i didn't find any msi file ...
Could you help me?
Taleb 03:12 Hello, I have a question:
i run after installing Wix-3.5 the command: prep2010 examples buildex
in the projects, I didn't find any WixProject and in the output
Could you help me?
taxilian 03:12 Taleb: There seems to be some issue detecting wix 3.5
We are still working through it
You could try 3 or try debugging it yourself
Unfortunately we are mostly asleep this time (and I am going back to sleep now)
kalev 04:12 taxilian_away: I'm doing my first posts on and found a recent question where I could tell about Firebreath
I doubt the poster is going to write browser plugins, but perhaps someone else sees it
iaincollins 07:12 hi all
kalev: best answer :)
kalev: Just been reading your answer on the mailing list to "catching standard exceptions"
I am generally a fan of "crash hard + early", especially in frameworks
but after reading your email to the list I am not so sure about which I prefer for the browser plug-in model
just because it is so obnoxious for an entire browser to crash (which most do) because of a component on a single page
jshanab_wcw2 07:12 Selectable
iaincollins 07:12 *nod*
(and now, let a divisive, bitter and protracted war over which should be the default commence...;)
jshanab_wcw2 07:12 LOL, I used to run plastic processing equipment. It had open loop and closed loop. You had to throw out all manuals and disable closed loop and get it as close as possible, then and only then enable closed loop control. I think this is a similar situation
taxilian 08:12 Heh
amackera 08:12 heh
taxilian 08:12 Anyone want to tackle the exception problem?
neilg_ 09:12 Which exception problem? The unhandled exception which can/will crash the browser?
I'm normally of the opinion that things should crash hard ASAP - but that's in applications. In plugins I can't think of a worse thing happening! So I do believe we probably should catch any uncaught exceptions by default, the question is what to do about them? We want to report that to the developers without necessarily warning the users
amackera 09:12 Raise a javascript exception, perhaps?
Or just log it and move on
neilg_ 09:12 Well, I know I'd prefer it to log it (on Windows) using something like OutputDebugString - but then I'm used to running in either the debugger or running DbgView
I don't think raising a javascript exception is the right thing to do because the user most likely won't be able to do anything about it (if they even care!)
But my opinion is based around the way I tend to work, I don't know if it would work well on all platforms in any case
amackera 09:12 Maybe if it's a debug build it should crash and burn (we're debugging here people!)
But if it's a release then it should catch the exception silently
and just log to file or even just ignore it
jshanab_wcw2 10:12 log4cpp is in there, which can redirect with different appenders to windows eventlog, off site, linux syslog and have levels. Seems like that facilty needs to be used
So log and throw in debug, log and recover in release? and leave the log level to the developer as settings in the project config?
taxilian 10:12 I like the discussion
I am leaning toward crash on debug not on release
Be back in a few
jshanab_wcw2 10:12 Sounds like it is a pair of settings in the project that default to what you just discused, during the fbgen but lets me, for example runa beta test, full logging but keep on going in a test environment
taxilian 10:12 well, I'm kinda liking the idea of an exception manager
that way we can have default settings, but the defaults can be overridden by overriding a function in FactoryBase, for example
the problem is that I really don't have the time to do it in a 1.4 timeframe
and 1.4 so far is really turning into a very major release
grr. I need to go get breakfast
I could get so much more done if I didn't have to eat :-P
neilg_ 10:12 If it's going to crash in debug then it should ensure it logs first - because if somebody doesn't have the debugger open then crashing is pointless (IMHO)
You're a true coder ;)
taxilian 10:12 I agree, however I still don't like the idea of forcing someone to use a particular logging system
and the way log4cplus is included right now is really not a good solution :-/
though... I might have an idea on how to improve it (just came to me)
so we could log it, but they won't actually get that log message unless they enable logging
taxilian 10:12 kalev: StackOverflow is one of our biggest sources of hits, according to analytics. Please use instead of the google code website, though (maybe even edit your answer); I'm trying to get links changed to the real website, as it's more useful.
amackera: any kind of ETA for when you'll be able to work on IE windowless plugins?
hmm. okay, it's becoming uncomfortable. I better go get food. *sigh*. be back in a bit; let me know if anyone wants to try to tackle the "catch all exceptions and handle them correctly" problem; not sure when I'll have time.
kalev 11:12 taxilian_away: okay, I will
regarding the exception problem, I have a use case where the underlying C++ library I use sometimes throws exceptions and I (mostly) just want to pass them on as javascript exceptions
so if I want to pass on the exceptions to javascript, I need to convert all the exceptions to FB::script_error, which makes the code look uglier than it has to
taxilian 11:12 kalev: my concern with just passing std::exceptions to javascript is that it may reveal information about the problem to people who could potentially use it for neffarious purposes (aka exploits, etc)
kalev 11:12 ah yes, that's a good point
taxilian 11:12 but we could do something like that in debug mode, for example
kalev 11:12 I think it's better to crash in debug mode then; it's not very intuitive if the exceptions are passed on to javascript in debug mode but not in release mode.
taxilian 11:12 unless they say something like "(debug mode exception): Unhandled C++ exception: <message>" perhaps?
I'm just trying to think of some way that you can find out what the actual exception was if you don't want a hard crash
kalev 11:12 or perhaps catch (FB::script error) { raise JS exception; } catch (std::exception) { DEBUG_LOG(...) }
taxilian 11:12 but DEBUG_LOG by default is a noop, unless you enable logging, which is an issue
kalev 11:12 so it wouldn't crash neither in debug nor release mode, but only get log output in debug mode
taxilian 11:12 I think what we really need is (as suggested on the list) an exception manager that can decide if it wants to raise the exception again or handle it in some way
we could possibly even have the default check a global const variable that is generated by cmake based on a PluginConfig.cmake value that could say crash hard, js exception, ignore, play random youtube video, etc on unhandled exception
but they could always create their own exception handler function
kalev 11:12 or perhaps the exception handler could be a virtual function in JSAPI that people can override
I mean, it should probably be specific to the instance of PluginAPI now that we are going to support multiple mime types
so the plugin might want to do one thing with exceptions if it's loaded by one mime type and another thing if it's loaded by another mime type
taxilian 12:12 kalev: hmm. I guess that would work in the case of JSAPI functions
we need something for other API areas that could crash the browser, though
starakaj 12:12 hey guys
so I've got what I'm sure is a realy dumb question about linking in libraries
taxilian 12:12 no worries, we love dumb questions
so much possibility for slander and ridicule
go for it
starakaj 12:12 alright, then you'll love this
so I'm trying to build a plugin for os x
taxilian 12:12 hmm. no, that actually sounds like a good diea
starakaj 12:12 right, so far so good
I tried building once without linking in any libraries
everything works, I go to build the xcode project, 10 billion errors because none of the libraries are linked in
fine, that's what I expected
but now I don't know how to get those libraries included
say I've got library.a
taxilian 12:12 are these mac specific libraries?
starakaj 12:12 offhand I don't know
I didn't write them
but I'm assuming no
amackera 12:12 You need to link them with your plugin
starakaj 12:12 so in my project directory I've got a folder called libraries and a library I want to include called library.a
here's what I tried, in CMakeLists.txt
set (LIBRARY_PATH ${CMAKE_CURRENT_SOURCE_DIR}/libraries/library.a)
target_link_libraries(${PLUGIN_NAME} debug "${LIBRARY_PATH}/debug/library.lib")
target_link_libraries(${PLUGIN_NAME} optimized "${SANDSTONE_DIR}/release/library.lib")
this is just copy-pasted from "using libraries"
taxilian 12:12 err.. why are you using library.lib if the library you want is library.a?
starakaj 12:12 I have no idea what's going on here
because I'm a fool
amackera 12:12 hehe
starakaj 12:12 well, changing that doesn't fix it
taxilian 12:12 oh, well, that makes sense then
okay, do you understand what target_link_libraries is doing?
starakaj 12:12 100% no
taxilian 12:12
amackera 12:12 If the libraries are named .lib they are probably for windows
does the linker complain about linking libraries compiled for a different architecture?
taxilian 12:12 that might help; all target_link_libraries is is a command that tells cmake "when you link this target (the target in this case being your plugin), link these libraries into it"
debug tells it to only use that library when compiling in debug mode
optimized tells it to use the library only when not compiling in debug mode
starakaj 12:12 hmm
the error I get when building is Cannot specify link libraries for target "Project" which is not built by this project.
amackera 12:12 Ahh
taxilian 12:12 you need to put target_link_libraries after the add_library command
which is in projectDef.cmake
if you're putting it in projectDef.cmake, you need to put it after the add_mac_plugin, if you put it in cmakelists it must be after the include_platform
gotta go take my last final. be back later
starakaj 12:12 hmm
so that got rid of my error
which is awesome, by the way
but the xcode project still can't find the library
by which I mean all my #import lines still say they can't find anything
amackera 12:12 You need to set the proper header search path, i believe
So firstly you'll need the header files corresponding to the libraries you're trying to link
then you'll need to tell cmake where to find those headers
starakaj 12:12 okay
amackera 12:12 i believe the cmake command is include_directories(<path/to/header/dir>), but I could be totally wrong about that
starakaj 13:12 no way!
I mean, not completely
99% still broken
but 1% awesome!
so much thanks, acres and acres of thanks
amackera 13:12 no problemo :)
taxilian 13:12 well, I just finished my last final
my final final, as it were
I don't *think* that I failed any of my classes
which is good
neilg_ 14:12 Congrats!
taxilian 14:12 neilg_: so have you tried out the multiple plugins thing yet? =]
neilg_ 14:12 Nope, I haven't had a chance yet :(
taxilian 14:12 tsk tsk ;-)
neilg_ 14:12 Though maybe I can get my colleague on it sooner. I shall ask!
I know, I know, this work thing and its "deadlines". Pfft. lol
taxilian 14:12 hehe
amackera 14:12 Heh, I hate deadlines
taxilian 15:12 and now to reboot back into Windoze
taxilian 17:12 I gotta say, these proxy objects are actually pretty cool