IRC Log Viewer » #firebreath » 2011-08-27

IRC Nick Time (GMT-7) Message
FireBreathBot 04:08 JIRA issue http://jira.firebreath.org/browse/FIREBREATH-120 issue created by sajty
Sajty 06:08 git pull request
FireBreathBot 06:08 1 open pull request:
sajty: FIREBREATH-120: Add support for GTK+ 2.12 http://goo.gl/vTZaa
taxilian 09:08 dougma: it may be that parentNode isn't set as a reserved property and is getting overridden
FireBreathBot 09:08 Commit 21b59f6 on master by Peter Szücs: "FIREBREATH-120: Add support for GTK+ 2.12.
Commit 090aee5 on master by Richard Bateman: "Merge pull request #28 from sajty/master
nd 09:08 Hi Guys, I am using latest clang compiler (from svn) and getting this error message:
firebreath/src/PluginAuto/Mac/np_macmain.cpp:26:9: error: first parameter of 'main' (argument count) must be of type 'int' [3] int main(NPNetscapeFuncs *browserFuncs, NPPluginFuncs *pluginFuncs, NPP_ShutdownProcPtr *shutdown);
Any ideas what I can do to avoid it?
taxilian 09:08 comment out main
main is there for support of older browsers
but clang doesn't support it
nd 09:08 So I can define _NO_MAIN.
I was worried about warings in PluginAuto saying not to change. Thanks
taxilian 09:08 well, in general you shouldn't change those files; however, clang is not officially supported yet
I'm still trying to figure out how to best deal with some of the changes in xcode4; apple sure broke a lot of stuff with that one
nd 10:08 Yeah, the reason we had to move to svn clang was we are getting very weired link time issues with 32bit plugins (for chrome) using llvm and clang in xcode4.0.2 is very very memory intensive (it was fine till 4.0.1). But now I can't go back to xcode 4.0.1 build.
taxilian 10:08 4.1 isn't quite as bad
you can also turn off indexing to help with that
nd 10:08 Indexing is turned off ages ago :). Yet to try 4.1 & Lion
linearray 10:08 xcode 4.2 is supposed to fix everything
(i read that somewhere)
taxilian 10:08 heh. well, it does improve things
but it doesn't completely fix the problem
helps a lot, though
linearray 10:08 are you running the latest beta?
nd 10:08 beta of?
linearray 10:08 xcode 4.2
nd 10:08 no. 4.0.2. My understand is 4.2 is for Lion. Still stuck on Snow Leopard
Btw, got this error: Undefined symbols for architecture i386: "_main", referenced from: -exported_symbol[s_list] command line option
taxilian 10:08 I am
linearray 10:08 there is a snow leopard version
taxilian 10:08 nd: there is a file that defines the exported symbols in the gen_templates directory; if you copy it to your plugin directory, you can change it and it will get used instead of the original
nd 10:08 ah. did not know that. let me try get my hands on if it available to nonpaying develoeprs
taxilian: let me try that
linearray 10:08 you will have to find your copy on the internet
or someone in the dev program
nd 10:08 Yup will try that.
taxilian 10:08 nd: yeah, if you're on the ios dev program or mac dev program you can get it
nd 10:08 taxilian: can I try change it via cmake?
I mean define the _NO_MAIN via cmake and it gets taken care of
taxilian 10:08 hmm. perhaps
try adding it with add_definitions in your pluginconfig.cmake
http://www.cmake.org/cmake/help/cmake2.6docs.html#command:add_definitions
well, I'm being incredibly lazy today, so I better actually go eat breakfast and get ready to do something useful
bbl
nd 10:08 Thanks taxilian.
linearray 16:08 boost::phoenix is awesome
taxilian 16:08 havne't looked at it
what does it do?
linearray 16:08 lazy functional programming
taxilian 16:08 hmm. sounds interesting
linearray 16:08 I wanted reasonable functors for STL algorithms, but now I feel like rewriting tons and tons of code with phoenix :)
taxilian 16:08 lol
have you found any good tutorial pages?
linearray 16:08 only the boost docs
http://www.boost.org/doc/libs/1_47_0/libs/spirit/phoenix/doc/html/index.html
taxilian 16:08 does this rely on boost::lambda at all?
linearray 16:08 no
phoenix is the quasi-successor to lambda and bind
taxilian 16:08 interesting
linearray 17:08 for some reason it's buried within spirit
taxilian 17:08 huh
I wonder if it requires spirit to run?
spirit is pretty cool, but it's huge
linearray 17:08 don't think so
there's all kinds of stuff within spirit/
taxilian 17:08 yeah
linearray 17:08 oh, it's a new lib in 1.47.0
linearray 17:08 ah, and in 1.47.0 it's no longer in spirit/
i am a bit slow today...
taxilian 17:08 lol
well, I'll have to pull it into the firebreath boost repo when I have time
linearray 17:08 what are the changes between boost and firebreath_boost, besides cmake files?
taxilian 17:08 firebreath-boost doesn't have as much
boost is a huge repository
and we don't use most of it
so rather than force everyone to download the entire boost repo and install it on their system, I just include it with FireBreath stripped of some of the less used components
linearray 17:08 ah, i c
3.9 MB vs. 47 MB
taxilian 17:08 yeah
bit of a difference, no?
=]
linearray 17:08 hmm
well, not that I really care :)
I'm used to downloading gigabytes of updates
windows and OS X come to mind
taxilian 17:08 hehe
well, it's not just the download
though that's why I only include a subset
it's also the pain of having to install tons of dependencies before using something
currently you need cmake, git (if you want it from source control) and a compiler
and everything else just works
that's moderately rare for a project like this
linearray 17:08 yeah and that's great
but what does that have to do with firebreath_boost?
taxilian 17:08 if I didn't use firebreath_boost, then they would also have to download and build boost before using FireBreath
which usually takes me about 30-45 minutes every time I have to do it
linearray 18:08 ah yes, building
taxilian 18:08 well, so it's two things; one is the building time (that's the biggest thing) and then it's also one less thing you have to go find and download
linearray 18:08 not really I think... you could just download boost with cmake like you do now
taxilian 18:08 every thing you have to go find and download before you can use something annoys people
whether it's a deal-breaker or not
linearray 18:08 sure
taxilian 18:08 building google products? painful. the stuff you have to install isn't usually that bad, but there are always about a half dozen of them
like I said; probably by itself that wouldn't be enough, but add the size, time to download, and the building time, and it's pretty significant
particularly on windows; for some reason extracting boost on windows takes, like, 10 minutes on most computers
there are a lot of people who decide not to use firebreath because it uses cmake, and that saves more time than it costs (though you have to know the system to understand that)
linearray 18:08 yeah but these people can't possibly have tried to use npapi by itself
otherwise they would realize that
taxilian 18:08 lol. you'd think
if you know what you're doing, aren't doing anything too complex, and don't care about IE, NPAPI isn't terrible
the reason FireBreath is so complex is because it solves pretty much every use case
and makes it all elegant
if you don't care about elegance and don't need multi-threading things and DOM access, etc, you can throw a lot of it out
linearray 18:08 wait... so for the boost libs that actually need building (like thread), you actually wrote cmake files, so they are built when the project is built
taxilian 18:08 yes
linearray 18:08 wow
taxilian 18:08 lol. go look at the cmake files
they're really really really simple
it didn't take much
linearray 18:08 I'd be less accommodating :)
"build boost, kthxbye"
taxilian 18:08 hehe. I could be, but the project wouldn't be as big as it is if I wasn't
linearray 18:08 probably true
taxilian 18:08 I am leaning more and more to having a commercial branch of some sort, though
not of the core, just of helper libraries
I'd give free access to those who have contributed, such as yourself, but there are so many who just take and don't bother even trying to help in return that it annoys me some days =]
particularly when they come in and seem upset that it doesn't work exactly how they want
linearray 18:08 what kind of libs?
and yes, you should definitely try to monetize FB a bit
taxilian 18:08 for starters, things like advanced drawing classes
linearray 18:08 that would be awesome :)
taxilian 18:08 another big thing that I would try to monetize would be walkthroughs, documentation, etc
I would do a set of how-to videos; "creating an MVC view", "linking plugin instances", "safely using singletons", etc
"using libraries with cmake"
access only to subscribers
and support contracts / options, etc
linearray 18:08 I guess what people would really love to pay for is service to make sure their plugins will run on the next iteration or browsers
plus: that's when people are already hooked on FB :)
or=of
taxilian 18:08 hard to guarantee that more than I already do; when something breaks, we usually fix it pretty quickly =]
linearray 18:08 hmm yes
but you might try FB on beta browsers
taxilian 18:08 yeah, I probably would if I was doing any sort of official support =]
I do sometimes anyway, but often not
linearray 18:08 hmm but maybe it's hard to put the fixes only in a private repo
and let them trickle down to the public one
not sure if that makes sense.
taxilian 18:08 yeah, I'm still not sure how I'll work that
I don't want to turn this into a closed source system
nor a system that small shops and individual developers can't use
but I do want to encourage larger companies to pay for some of the time I'm/we're saving them
linearray 18:08 hmm
maybe only give away major versions and reserve -dev for subscribers
of course that's quite the opposite of what we were discussing before: being accommodating to attract developers :)
taxilian 18:08 that's actually not in my best interests; most bugs are found by users, despite my best efforts to test
linearray 18:08 yeah and oracle tried that with solaris... look what happened to them
taxilian 18:08 in fact, ti's one of the main advantages to having an open source project
yeah; you have to find the middle ground
find the sweet spot between being greedy and being foolish =] right now it's probably a little too close to the "foolish" side of the spectrum where it's so open that some companies don't even trust it
but if I go too far the other way, not only do I lose track of the spirit of why I started the project but I will hurt the project as well
linearray 18:08 maybe, just maybe, GPL would work just fine :)
taxilian 18:08 lol
no
absolutely not
that would *completely* destroy the project
linearray 18:08 hmm
taxilian 18:08 the one possible variation on that would be to release it GPL for the free license and sell a commercial license
linearray 18:08 yes
taxilian 18:08 but that would make it almost unusable for smaller shops
linearray 18:08 that's what I meant of course
:)
taxilian 18:08 ahh
okay
linearray 18:08 GPL's only good use is to sell exceptions ;)
taxilian 18:08 heh. yeah
but again, then anything anyone contributed I'd either need a complex contribution agreement or it'd only be good for one or the other...
JUCE is licensed that way, and I'm just not really happy wtih the idea
linearray 18:08 to go back to where we started: can I just put a boost-1.47 in firebreath_boosts place and build it?
taxilian 18:08 no; the cmake files would be missing
if you copy the cmake files in, though, yes
linearray 18:08 I'll try that
taxilian 19:08 what are you trying to accomplish?
linearray 19:08 get Boost::Phoenix :)
the 1.47 version has more functionality than the 1.45 one
taxilian 19:08 you know about WITH_SYSTEM_BOOST?
linearray 19:08 nope
taxilian 19:08 !wiki WITH_SYSTEM_BOOST
FireBreathBot 19:08 3 results found. Note: Results limited to 8
"Prep Scripts": http://goo.gl/VnMXJ
"Old Versions": http://goo.gl/CNxWs
"Version History": http://goo.gl/lgWpo
linearray 19:08 pretty cool, thanks
taxilian 19:08 sorry, I didn't realize you weren't aware you could use system boost =]