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

IRC Nick Time (GMT-7) Message
kalev 01:10 taxilian: no, the crash actually happens
taxilian: try for yourself: go to http://www.colleduc.ee/~kalev/FBControl.htm and click on 'set event handler'
to be fair, your were right: the crash doesn't happen for 'NULL', but it happens for 'null'
the reason why I showed you the patch in the first place was that I didn't think it belonged in there either :)
but I have no idea how to fix the conversion to throw an exception instead
for some reason the above crash test code works fine in IE.
cygmatic: hey, I was just talking to (sleeping) taxilian, but maybe you can help me instead
cygmatic 01:10 maybe, whats up?
kalev 01:10 it's possible to get Firebreath to crash by running obj.addEventListener("asdf", null, false) in Firefox
note that it doesn't crash for NULL, only for null.
a quick workaround is http://fpaste.org/neTA/
but this is probably not the right place to fix it; the conversion from null should probably throw an exception instead
I have a test page for that: go to http://www.colleduc.ee/~kalev/FBControl.htm and click on 'set event handler'
cygmatic 01:10 hm, it would probably be better to make that an unique type
kalev 01:10 so my problem is that I am unsure what is the right way to fix this. The quick hack works, but it's probably not the right place.
cygmatic 01:10 i.e. make NPVariantType_Null map to something like FB::NullType
that way you get a conversion exception too
kalev 01:10 awesome, that should get me started
thanks!
cygmatic 01:10 no problem and good find
NpapiBrowserHost::getVariant() is where it's implemented
dunno what taxilian says but in my opinion a distinct null type would be better
kalev 01:10 oh, it's actually something caused by a taxilian's commit
looks like a deliberate change: http://code.google.com/p/firebreath/source/detail?spec=svn32043af3377185d418c062ce993d3548be7af3a6&r=47008b6ac94ff893b352b3d86ff8ce2b5e1e4270
- retVal = NpapiNull();
+ retVal = JSObjectPtr();
cygmatic 01:10 ok, that was a Npapi::NpapiNull
well, in the short run your fix should do it
kalev 01:10 I'm afraid that there are more places that are going to crash in a similar manner
cygmatic 01:10 for the rest lets wait for taxilian to see if there was a specific reason?
kalev 01:10 allright
okay, pushed.
neilg_ 08:10 Morning all!
iaincollins 08:10 afternoon :)
kalev 08:10 Morning!
taxilian 09:10 kalev: have you ever actually seen a null method?
'cause I'm fairly certain that it isn't possilbe
kalev 09:10 yes, I have
taxilian: try this page with the test plugin: http://www.colleduc.ee/~kalev/FBControl.htm
neilg_ 09:10 Quick CMake question - in common.cmake there is a macro "link_boost_library". I'm assuming (which could be the mistake!) that something must call this in order for the boost libs to be linked into the FB plugin. Does anybody know where?
kalev 09:10 click on the 'set event handler' link
neilg_ 09:10 I need to add more things to link against in my plugin - then hopefully I can generate everything with CMake!
taxilian 09:10 kalev: I don't have time to try it right now, but it actually passes a null object? odd. I didn't think that would work
maybe cygmatic fixed that at some point
neilg_: you know how to add target_link_libraries to your plugin with cmake, right?
kalev 09:10 taxilian: yep, that's exactly what's happening
taxilian: I think this change caused it: http://code.google.com/p/firebreath/source/detail?r=47008b6ac9
- retVal = NpapiNull();
taxilian 09:10 interesting. Well, that's probably a good thing, so we'll leave it
kalev 09:10 + retVal = JSObjectPtr();
taxilian 09:10 ooh.. did I do that?
kalev 09:10 yep
neilg_ 09:10 Sure but I figured I'd do that in the same place that called "link_boost_library" except I can't find where that's done. :)
taxilian 09:10 I thought about it, didn't think I'd actually done it :-P
kalev 09:10 so I'm afraid that there might be some other places with nulls being passed through
taxilian 09:10 neilg_: boost libraries are special cases in FireBreath; you can put that in PluginConfig.cmake (I usually do add_boost_library, though)
kalev 09:10 my "fix" is more like a hotfix; I'm thinking it should really just throw an exception in the conversion code.
taxilian 09:10 neilg_: to add links, put it in either CMakeLists.txt or <platform>/projectDef.cmake depending on whether it is cross platform or platform specific
amackera 09:10 morning/afternoon all :)
neilg_ 09:10 Morning!
Thanks, I'll do that
taxilian 09:10 amackera: good to see you =] any chance you could fix the windowless stuff to use the new factory in the next day or two? you can even remove those ifdefs that you worked so hard on… :-P
amackera 09:10 lol sure
those ifdefs are so beautiful though
it's a shame to remove them :P
taxilian 09:10 yeah, I know
parting is such sweet sorrow and all that
neilg_ 09:10 One thing I'd never worked out with CMake is how to link against different libraries for the build configuration - so link against one library if building Debug and another if building Release. Is that possible?
taxilian 09:10 yes, it is
I'd have to do some digging
neilg_ 09:10 If you don't know then I'll continue looking - it's just hard without knowing which keywords to use. I just thought I'd ask just in case! :)
amackera 09:10 neilg_: that's a good question
taxilian 09:10 kalev: do you know?
amackera 09:10 sadly no
taxilian 09:10 I've done it before, but I can't remember offhand
neilg_: one way that I know works is to add it to the LINK_FLAGS_DEBUG or LINK_FLAGS_RELEASE target properties
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:set_target_properties
oh, even simpler
http://www.cmake.org/cmake/help/cmake2.6docs.html#command:target_link_libraries
A "debug", "optimized", or "general" keyword indicates that the library immediately following it is to be used only for the corresponding build configuration.
that should do it
amackera 09:10 i think you must use full paths to the library if you do that
taxilian 09:10 yeah; use the target_link_libraries method
neilg_ 09:10 Cool, that seems like exactly what I need. Thanks!
taxilian 09:10 ok, guys; I gotta head to class, but I just fired off the nightly build with a change I put in (just for you, kalev) to properly support null parameters
amackera 09:10 sweet
taxilian 09:10 everyone please try it out (it'll be rc-1.3.-nightly build 60) and let me know if there are problems. I will release RC3 this afternoon
my hope is that this will be the last RC until 1.3 =]
cya
neilg_ 09:10 Bye!
kalev 09:10 taxilian: awesome, thanks, but I have a small problem: the change doesn't appear to be in the hg repo
taxilian 10:10 amackera: I take it it came back up
amackera 10:10 looks like it's back :P
brb
taxilian 10:10 interesting
wonder what happened
btw, I didn't get the change pushed that I thought I had, so build 61 is the RC3 RC :-P
neilg_ 10:10 I guess I'm still confused about linking. :( I've added a target_link_libraries() to my CMakeLists.txt in one of my plugin directories. But for some reason PluginWindow is then bringing in that CMakeLists.txt and so I get an error from CMake
The error is "Cannot specify link libraries for target "SandstonePocket" which is not built by this project."
SandstonePocket is my plugin
...unless it's meant to go into projectDef.cmake?
cygmatic 11:10 neilg_, yep it is
amackera 11:10 you got it :)
neilg_ 11:10 Damn. I should probably try these things before asking. :) Thanks guys!
(That worked)
amackera 11:10 I find CMake to be quite difficult to use, and it's entirely because I found it hard to find any good documentation/tutorials
It's not really cmake's fault
and there's not really a good alternative
neilg_ 11:10 I have the same problem
cygmatic 11:10 hm, i see i'll have to clarify that in the "using libraries" page later
oh wait, it's already there :)
http://www.firebreath.org/display/documentation/Using+Libraries
neilg_ 11:10 I actually have two issues with CMake - one is that sometimes it won't pick up changes you make in CMakeLists.txt. In fact, annoyingly, it picks up some changes but not all - include paths is a very good example of changes it doesn't seem to pick up. That's CMake's fault and the solution is to remove the build directory and start a clean one.
The other is lacking documentation
But you're right, there's not a good alternative at all
I mean, there's SCons and JAM but... Ugh.
taxilian 11:10 neilg_: That's odd; I've never run into the cmakelists.txt problem in 2 years of using it; what kinds of changes aren't being picked up?
nitrogenycs 11:10 scons is great
not like 80s cmake :)
neilg_ 11:10 If I have a set with my include paths and then include that doing something like INCLUDE_DIRECTORIES(${MYINCLUDE_DIR})... Then I come back and add a path to that set, CMake doesn't pick it up
SCons is great for small projects. It gets exponentially slower with larger sets of files
It's better than JAM though - I'll give you that. ;)
nitrogenycs 11:10 That would have to be tens of thousands of files then
neilg_ 11:10 And I love Python so I should love SCons. Just was in a team working with SCons which was used to build assets for a game
nitrogenycs 11:10 :) I've written the same
an asset build system for out game with scons
our
neilg_ 11:10 You could always tell when people had commited new assets because the builds got longer... and longer... and longer. :)
nitrogenycs 11:10 we've also used it for the code
we've never had any issues with that really
how many files did you have?
just roughly
kalev 11:10 taxilian: hey, thanks for fixing the null parameter issue
neilg_ 11:10 I know it works well with the code I've used it with
You were probably on the money with tens of thousands
nitrogenycs 11:10 okay, I've only tried with lower tens of thousands counts
it was still just a few seconds though (without build time itself)
taxilian 11:10 kalev: Can you test it to make sure it now behaves as expected?
neilg_ 11:10 Most of the assets weren't even referenced by the end of the project and weren't being changed
taxilian 11:10 I'm still not totally happy with the solution, but I don't think there is a good one
neilg_ 11:10 We were seeing 5-10 minutes just to do the dependency checking before it even started building
kalev 11:10 taxilian: I just did, and at least with Firefox it works fine now
nitrogenycs 11:10 wow, that's strange
cygmatic 11:10 taxilian: why not use an explicit "struct FB::NullType {};"? "variant_detail" is supposed to hold implementation details
nitrogenycs 11:10 neilg_: did you try mailing the scons-user list?
neilg_ 11:10 I personally didn't because I was on the networking side and didn't work with it directly. It was the other 3 team members from my team who were constantly trying to make it faster
nitrogenycs 11:10 neilg_: there were many cases where people had build times like that. Usually they ran the build over a network or had issues in their custom builders and such
neilg_ 11:10 We'd originally started off using JAM and had issues where it wasn't picking up dependencies - an email was sent to the list and 9 months later there was a reply. At that point we'd already switched to SCons
nitrogenycs 11:10 neilg_: hehe
taxilian 11:10 neilg_: My plan to help deal with the cmake issues is to create a branch of documentation on the site about how to use cmake
the cmake docs aren't bad, but only as reference
neilg_ 11:10 It's entirely possible that we were using it incorrectly (or at least in a bad manner!). :)
taxilian 11:10 they are terrible for learning
nitrogenycs 11:10 neilg_: maybe you also hit some kind of dead spot in it, who knows. I'm just always surprised that some people are so disappointed by scons performance
neilg_ 11:10 taxilian: That would be very useful. I'd figured out most things from examples - but most examples were very simple one file CMakeLists.txt
More advanced things with CMake are currently beyond me :)
taxilian 11:10 neilg_: If your'e willing to start putting things on the wiki, I'll update them and answer questions for you on how to do what you need to do
I've gotten (through lack of choice) fairly good with cmake
nitrogenycs 11:10 neilg_: may I ask for which company you work?
neilg_ 11:10 nitrogenycs: I know that we were only using SCons for dependency checking so that we could kick off our builders
I currently work for Muzzy Lane (www.muzzylane.com) but I wasn't with them back then
neilg_ 12:10 Is there any way to not generate some build configurations using CMake? RelWithDebInfo doesn't build because it can't find the boost thread lib - but it works for the other 3 configs
Hmm, I can possibly do it through CMAKE_CONFIGURATION_TYPES - but it's worth knowing that the FB generated stuff doesn't build for that build configuration if you're using a system Boost
taxilian 12:10 neilg_: what do you mean by "some build configurations"?
neilg_ 12:10 Well, Debug, Release and the MinSizeRel configs all built correctly
RelWithDebInfo failed to link with the system Boost thread lib
taxilian 13:10 that's weird
I have no idea why that would happen
check buildconfig.cmake and see if anything in there sheds any light on things
kalev 13:10 I bet it's a bug in FindBoost.cmake which ships with cmake itself
neilg_ 13:10 Me either. I "solved" it for now by only creating Debug and Release configs - which are the only two that matter to me in any case
I'd bet you're correct about that though
taxilian 13:10 that is quite possible
amackera 13:10 Any ideas what this means from the prep scripts: CMake Error: Remove failed on file: C:\cygwin\home\Anson\workspace\firebreath\build\CMakeFiles\CMakeTmp\Debug|cmTryCompileExec.exe: System Error: no such file or directory
taxilian 13:10 try nuking the build dir and run prep again
most such errors can be fixed that way
amackera 13:10 hmmm negative
taxilian 13:10 hmm
odd
I don't know
anyone know of a reason that I shouldnl't release 1.3.0 RC3?
amackera 13:10 hmm windowless fixes for new factory aren't finished yet
wait
nvm, windowless is not in 1.3
sure i'm okay with RC3
kalev 13:10 can you hold some 10 minutes? I'm hoping it finishes compiling in a few minutes so I can test under IE.
taxilian 13:10 absolutely
amackera: that's why I haven't been breathing down your neck ;-) it'll be nice to have that fixed in 1.4, but it's not urgent like it would be if it were in 1.3
amackera 13:10 :D
taxilian 13:10 I also slipped in a change for nirvdrum last night so that you can override the generated config files (such as the .def or .reg files) by copying said file to your plugin project
it will then use that from now on
should have done that ages ago
kalev 13:10 taxilian: okay, everything seems to work fine here.
taxilian 13:10 kalev: great
I'll push out the RC3 now
neilg_ 13:10 Sorry for the delay! The only reason I can think of to delay RC3 is BrowserStream not working properly (which I have local fixes for...)
taxilian 13:10 hasn't caused problems yet; those can go in 1.4
rather, you're the first to care ;-)
cygmatic 13:10 hm, has anyone any interesting ideas of combining browser plugins and parallel computation into one project?
could make it into a course project then
kalev 13:10 MD5 hash cracking program which uses GPU for parallel processing and uses web page for UI
taxilian 13:10 lol
and you could even build it into an extension to use against certain websites… as a proof of concept, of course
cygmatic 13:10 hm, i guess that falls into the category of "why make it a plugin" ;)
taxilian 13:10 because otherwise you're stuck with doing the parallel processing in javascript
cygmatic 13:10 "why make it a plugin and not an app - you have to install it anyway"
kalev 13:10 true.
taxilian 13:10 it's more convenient to be right there on the page that you're trying to hack into, though!
;-)
kalev 14:10 next idea: implement blazing fast sorting algorithm which beats the sorting alorightms that the browser's JS engine implements. (hint: plugin + GPU for parallel processing)
taxilian 14:10 lol
that would be cool
cygmatic 14:10 hm, does anyone work with big enough data sets that it'd matter? :)
i'm surprised, i thought there should be some easy idea there for a possible example plugin or something - but i've come up short
cygmatic 14:10 whoa, where did all that features in 1.3 come from? ^^
taxilian 15:10 cygmatic: this the first you've looked at the changelog for 1.3?
now you see why I decided to release it without the other things we'd talked about =]
amackera 15:10 I personally love big fat changelogs :D
Man that add_boost_library stuff has been increadibly useful, by the way
taxilian 15:10 good
I kinda liked it =]
and as we add useful things, I think add_firebreath_library will be equally useful
I have openssl and curl already in 1.4
amackera 15:10 Sweet!
I didn't realize curl had a library!?
taxilian 15:10 what I do on windows is if I don't detect that they have it installed, I pull down the static link lib from the repo
curl *is* a library
it's more suprising to me that it has a command line tool
amackera 15:10 Haha, awesome! I've had it backwards the whole time haha
taxilian 15:10 I first used curl in php
amackera 15:10 Oh man, so here's a funny story
I inhereted a bit of my existing code base
and the sprite class needs to download images from a URL and cache them locally
and the person from whom i inhereted the code decided the best way to do that was to use the command-line curl
and since I didn't know about libcurl i thought that seemed reasonable, hehe
But now I'm going to tear out all that and just use libcurl directly
plus it means portable code for retreiving URLs, since libcurl presumably works on windows also
i should say for retreiving resources designated by URLs, i suppose
or do we call them URIs now?
curi? doesn't have the same ring to it
taxilian 15:10 lol
taxilian 15:10 well, there is a URI class in ScriptingCore as of 1.4 (and right now)
taxilian 16:10 amackera: awesome, thanks
taxilian 17:10 wow.. our first piece of spam
for now, I set that member not allowed to post
but changed their perferences to receive mail instead of no mail =]
we are up to 119 members on the mailing list
amackera 17:10 Not bad!
taxilian 17:10 'course, I bet a lot of those aren't set to receive email
but still