IRC Log Viewer » #firebreath » 2010-09-30

IRC Nick Time (GMT-7) Message
taxilian 00:09 kylehuff: the changes are pretty minor
WarGloom_ 06:09 hello, anybody knows how to access to com object based on firebreath from anather application?
taxilian 09:09 amackera, kalev, nirvdrum, nitrogenycs: please take a second and fill out the survey I just send to the list
amackera 09:09 sure
amackera 10:09 taxilian: would it be possible to use a param passed to a plugin when negotiating windowed/windowless?
taxilian 10:09 yes
I checked, and the params are set before the negotiation happens
amackera 10:09 how would one get access to them?
i need them in NpapiPluginWin
taxilian 10:09 wow, I should have done this survey thing sooner
only 3 responses so far (in the whole, what, 20 minutes since I posted it?), and I'm pretty sure one was you, but I still have gotten some useful feedback
hang on, let me go look at something again
amackera 10:09 sure
and yes, one was me :)
taxilian 10:09 so far all three are in favor of keeping boost in the tree
you realize the .zip file size is up to 8MB? and only about 1MB of that is actually FireBreath? =]
lol. I take it back; the 1.2.1 release that got accidently put out w/out boost, the zipfile is 434kb
nitrogenycs 10:09 when I read the "Plea for help" mail title I thought they found your logo xD
taxilian 10:09 lol
no, that was just in hopes people would actually read it :-P
They might not care
about the logo
nitrogenycs 10:09 :) ya
taxilian 10:09 and it might actually be perfectly legal
I'm just not 100% certain
so if they send me a threatening letter, I'll just remove it and say "sorry!"
or maybe just remove that 1/4 of the logo…. :-P
amackera 10:09 lol
nitrogenycs 10:09 :) i'm off to fill out the survey for a second, let's hope you don't ask inappropriate questions :)
taxilian 10:09 lol
only a few
amackera 10:09 1) what are you wearing ;)
taxilian 10:09 2) no, seriously; you can trust us. we won't tell
btw, amackera, if you log into you can see the survey results
nitrogenycs 10:09 done
taxilian 10:09 yours is the making it a library one? (unless you'd rather remain anonymous)
nitrogenycs 10:09 :) yes
taxilian 10:09 by auto-updater, you mean something for auto-updating the plugin itself?
nitrogenycs 10:09 it's the most annoying part, but I've accepted I have to live with it
yes, although I am not sure if it should go into firebreath itself. It might be too application specific
Maybe that's another project
taxilian 10:09 hehe. I've been thinking about that part, and we might be able to at least improve things somewhat
well, it might be a firebreath project by itself
if you decide you have some cycles to spend on it, I have had a plan for that since I started FireBreath
just no time to work on said plan
nitrogenycs 10:09 With auto-updating I guess I mean deployment in general. For example you need to install into the user's folder instead of the program files folder if you ever want your application to auto-update
taxilian 10:09 the MSI already does that, btw
nitrogenycs 10:09 Yes, but I am using my custom installer anyways
InnoSetup based, because I am already using that for all the other parts of my project
taxilian 10:09 makes sense
nitrogenycs 10:09 So I need to copy the features that the MSI one has
taxilian 10:09 though I have some very specific reasons why I think an MSI is the best aproach =]
it is much cleaner for updates
however, like I said; I have a plan that covers most if not all of that =]
just need to find time to implement it
let me know if you want to help
nitrogenycs 10:09 yes, I have never used MSI. I've used InnoSetup for a couple of things and it worked nicely enough all the time. It's a bit hairy if you want to extend it with that Pascal language.
There's also the nullsoft thing
But that had an assembly like extension language iirc xD
I don't have time at this point. I might come back at it later if nobody beats me to it
I also have some kind of auto-updater already going, but it's specific to my project
taxilian 10:09 so the main reason I prefer MSI to anything else
is that it isn't a language based installer
that really threw me at first
but it has a significant advantage for COM or NPAPI components;
since it keeps track of the exact operations you perform, it can reverse them to uninstall
so you don't end up with things accidently not getting cleaned up
even on an upgrade
nitrogenycs 10:09 My plugin can basically execute arbitrary code (python). The code is signed, then the plugin checks if the code was signed with the same certificate as its own. Then it starts a broker process which I register during installation which runs in medium integrity mode. The python script can basically do anything it wants, just like auto-updating.
taxilian 10:09 change the way your install structure works? No problem; it removes the old one before adding the new one. No chance of problems
cool. what are you using to interface with python?
nitrogenycs 10:09 yes, I agree MSI might be a better solution than InnoSetup. I possibly switch later, but there are so many other things to do that I can't be bothered to rewrite all of the installer-generation scripts etc :)
I am shipping a stripped down interpreter with my plugin
taxilian 10:09 I totally understand that concept =]
nitrogenycs 10:09 It can later download libraries it needs. I just used python, because I am using it in many other places, too
taxilian 10:09 cool
is that something you might be willing to share?
I'm in the process of building a method for including third-party firebreath libraries
already got it working with boost; simply call add_boost_library(filesystem) for example in cmake and it will add the project if neccesary
nitrogenycs 10:09 Yes, but I won't be in the position to refactor it for integration. I wrote a small library for IPC for it as well, because I couldn't find a suitable library. Build system is scons. So I am not sure if it's that easy to extract and re-integrate.
taxilian 10:09 if you have time, tar it up and email it to me sometime
I may not have time to extract and integrate either
but I'd be interested in at least looking at how you did it
nitrogenycs 10:09 The feature is of limited use to many people I guess. After all the code has to be signed. This means it can't work like flash where Adobe installs the plugin and everybody can write content it reads.
taxilian 10:09 one of the things I've wanted to do for awhile is have some options for embedded scripting languages in firebreath
nitrogenycs 10:09 sure
taxilian 10:09 actually, I consider that a plus
nitrogenycs 10:09 yes, it depends on your use case. If you want to write something like flash, then it's bad
taxilian 10:09 yeah… but if you want to write something like flash, you'd better be making a lot of changes to what you have to sandbox things
so I don't *want* people to be able to easily do that =]
the last thing we need is for FireBreath to become known as the source of all security issue plugins =]
nitrogenycs 10:09 I also might change the system a bit later. So the plugin does not only compare with its built-in license, but also with one which can be fetched from somewhere. I am not sure about the security/being-offline consequences yet though
yes :)
I also figured I can't guarantee that there will be no security holes
Also I don't want to be limited to a declarative/sandboxed language
taxilian 10:09 yeah
that is, honestly, exactly the type of thing I want to have available in FireBreath
as a "not included by default, but easily useable"
nitrogenycs 10:09 yes, an option
taxilian 10:09 I'm thinking of adding a source dir that you can either configure with a cmake option or it will default to look in a certain place
and you can use add_firebreath_library(simplepython) or something along those lines
and it will just add it for you
put that in your pluginConfig and off you go
of course, my master plan is to have a "donation mandatory" web-based fbgen that you can use to specify what all you want in your project (which platforms to support, which events to handle, build your JSAPI classes, etc) and have it do most if not all of the initial configuration for you
which will hopefully offset the cost of the web server it runs on enough to make it possible for us to do some other things
of course, "donations" don't have to be monetary =]
nitrogenycs 10:09 :)
You could put a "Donate" button
not sure if they work
taxilian 10:09 they work, but not necessarily well
nitrogenycs 10:09 ok, never tried that :)
taxilian 10:09 I want to make some kind of system so that when people donate, they get something out of it
even if it's just "priority email support"
which, of course, is something I tend to give everyone anyway
but they don't all know that :-P
nitrogenycs 10:09 I think people who pay are often backed by companies. So if you sell some for of consultancy you can probably get more money. Of course that also means somebody has to do the consulting xD
Yes, but even if they know I think companies always see what kind of support there is.
taxilian 10:09 right
that's what I'm thinking; higher "donations" will also have 1 phone support call, or some such
and high enough donations have attached lower than normal consulting fees
or something along those lines
nitrogenycs 10:09 I'm talking about the sector I know of which is gaming programming. There are lots of open source engines like ogre around.
taxilian 10:09 the problem of course is that I have so little time I can't guarantee fast support
I think you're spot on for most of the industry
nitrogenycs 10:09 But there are far more people using things like unity and torque. These are engines you can test/limited-use for free and for the full version you have to pay. You can also buy support etc.
taxilian 10:09 yeah, I don't want to make this a "you have to pay to really use it" type of thing
nitrogenycs 10:09 To me this shows that people WANT to have somebody they can pay to solve any problems/feature requests
taxilian 10:09 but I do want to eventually have a paid support type option
with value-adds
nitrogenycs 10:09 yes. Initially it might seem that making a project generator is not much of a value maybe. Just my first impression when I hear about it, a lot of other people might view this differently
taxilian 10:09 that's because to you using fbgen on the command line is easy
nitrogenycs 10:09 plus people can just copy the code output by it
taxilian 10:09 you'd be shocked how many people can't get fbgen working =]
but that would mainly just be a convenience perk for donations
nitrogenycs 10:09 :) Yeah, I already had python and stuff running. Just had to execute the file
taxilian 10:09 and if it does enough, it will save people potentially hours of figuring out how to set up their JSAPI objects and configure the project correctly
nitrogenycs 10:09 yes, the generator in itself is a good idea
taxilian 10:09 so no, not a huge thing
but helpful
nitrogenycs 10:09 yes
It might also save you from answernig many emails :)
taxilian 11:09 lol. might help =]
nitrogenycs 11:09 I am an extjs user since a few days/weeks. They have a similar model.
All their code is dual-licensed. They have GPL and the commercial license
So you can use the code if you want GPL in any way you want
taxilian 11:09 yeah, JUCE is the same way
nitrogenycs 11:09 but if you want to use it commercially without having to distribute your own code you can buy the license
amackera 11:09 that license model makes sense to me
or rather license scheme.. not really a model
taxilian 11:09 yeah; I considered it initially
but I decided I'd rather just leave it open, as it encourages growth in the community more
I'm not really doing FireBreath to make money
I'd just like to find little ways to have it support itself
and possibly other projects I work on =]
so far it's worked pretty well
it's directly responsible for 2 of my last 3 jobs
nitrogenycs 11:09 :) nice
You could split work with amackera or cygmatic. So if you have little time or are on holiday then they can jump in. Ofc I don't know if amackera or cygmatic want to do this at all :)
taxilian 11:09 If I start offering support stuff, I would definitely have to do something like that
I think cygmatic would be at least interested, but the problem is none of us have a lot of time
nitrogenycs 11:09 yeah, I know that situation. Also 100 users on the firebreath userlist probably don't make for enough paying people so you can make more of a living from it
taxilian 11:09 right
it would be side projects only
it's just not a mainstream market
there are relatively few actually good reasons to use a plugin
nitrogenycs 11:09 yes, plus writing a plugin is rather fast when you already have firebreath. You'd have to couple it with other stuff, so each contract would get longer.
taxilian 11:09 right
then again, maybe that means that there is little enough work needed to use it as a source of potential jobs and side work =]
nitrogenycs 11:09 I think in the future there will be many good reasons to use a plugin
taxilian 11:09 except that with 16 credits of school + 20 hrs of week + wife + 15 month old son, time <= 0
nitrogenycs 11:09 So far I've always worked with desktop GUIs like wxPython/wxWidgets etc. This is the first time I am going with a web-based GUI. And it's really really good. Web GUIs are way more advanced now than I thought.
taxilian 11:09 yeah
you can do a lot of really cool things
nitrogenycs 11:09 Unfortunately I can't use browsers to store lots of data or upload multiple files or run my native code
taxilian 11:09 however, if you can do it without a plugin, it's much better
nitrogenycs 11:09 so the plugin is perfect
taxilian 11:09 and they're getting to where you don't need that stuff as much
nitrogenycs 11:09 yes
taxilian 11:09 since plugin install is, frankly, hell
nitrogenycs 11:09 I think it makes sense for intranet uses
taxilian 11:09 absolutely
nitrogenycs 11:09 you often have stuff you can't do in a browser
certain libraries etc
taxilian 11:09 smaller more controlled groups
nitrogenycs 11:09 javascript is also not the most advanced language
taxilian 11:09 javascript is more powerful than most people give it credit for, though
nitrogenycs 11:09 Yes, but just if you come from the C++ side imo :)
taxilian 11:09 lol
nitrogenycs 11:09 It's not too bad. But other scripting languages are less quirky and more powerful imo.
I've started in C++
taxilian 11:09 I know a guy who would fight you over that ;-) he feels that javascript will take over the internet
nitrogenycs 11:09 nowadays I just use scripting languages for most of the stuff
taxilian 11:09 personally, I'd rather have python in the browser; that would be awesome
nitrogenycs 11:09 C++ is really ugly
taxilian 11:09 hehe
nitrogenycs 11:09 Yes, but python can't easily be sandboxed, too
JavaScript is not bad
It's not too hard to pickup
It's not as cumbersome as C++
It's fast
amackera 11:09 JavaScript is friggin' amazing
nitrogenycs 11:09 So I think javascript might really take over the net if you don't think it already has
But I'd still contend there are better languages :)
amackera 11:09 javascript is the worlds most successful language
taxilian 11:09 hehe
amackera 11:09 the good parts of javascript are awesome
the bad parts are awful
nitrogenycs 11:09 Yes, Microsoft is the most successful company. That doesn't make it the best :)
taxilian 11:09 lol
nitrogenycs 11:09 Although they have parts :)
amackera 11:09 first-class functions and closures are so unbelievably powerful
nitrogenycs 11:09 I think future languages will also have to pay a lot more attention to parallel-programming. Currently all of that is a nightmare imo.
python has those since 20 years :)
taxilian 11:09 lol
amackera 11:09 yeah, so has lisp
so has <insert whatever>
nitrogenycs 11:09 yes. I agree about it.
Although closures can start to bite if you care about GC
taxilian 11:09 so amackera, if I start offering paid support for FireBreath, are you interested in being one of the consultants who provide it? =]
amackera 11:09 hmm
taxilian 11:09 note that pricing would probably start at $150/hr
with a possible break for people paying support contracts
amackera 11:09 well, in a word, yes i'd be interested
taxilian 11:09 I'll let you know when I get closer to actually doing something about that and we can talk details
amackera 11:09 my currently employer might have issues with me taking time to work on contracts, but we'll figure it out if/when it becomes a possibility
taxilian 11:09 I'm guessing there wouldn't be a lot of work, but I'd need more than just me available
excelent; I have dependencies working nicely
will add also dependencies for date_time, filesystem, regex, system, and thread
since boost log depends on them
ok; bare minimum logging; is something that only accepts a std::string good enough?
nitrogenycs 11:09 maybe a wstring :)
taxilian 11:09 I think that's doable
my goal is to put something in that you absolutely don't have to use =]
but if you include boost::log it will use that for it automatically
so you can still get log messages from the core
but you can make them go to whatever logging system you want
or none
in order to do that, I basically have to keep it really really simple =]
nitrogenycs 11:09 I think that functon is enough. If you are really crazy you might want to include a priority
so you can filter out debug messages etc
taxilian 11:09 yeah, I'm thinking of doing the standard 5 priorities
and maybe allowing a "key" that could optionally be used for filtering
but can be ignored
I'm kinda counting on the compiler to optimize out the call if there is nothing in it
amackera 12:09 So my plugin uses boost::thread, can I just use the FB boost files? does it automatically link against my plugin?
kylehuff 12:09 amackera: yes, if you have a version that ends with "withboost"
taxilian 12:09 amackera: actually, 1.2.2 has boost embedded
so you don't need a "withboost" file
that was just 1.2.1
amackera 12:09 does the dev repo have boost included?
taxilian 12:09 yes
in fact
if you need anything else, like filesystem
amackera 12:09 awesome :)
taxilian 12:09 you can put add_boost_library(filesystem) in your pluginconfig
and it will automagically add it and link it for you
amackera 12:09 so awesome
is add_boost_library(thread) required? or is it automatic since FB uses thread?
taxilian 12:09 it's automatic since FB uses thread
however, if you want to put it in there it won't hurt
in that case it would be mostly just for documentation
amackera 12:09 i see
taxilian 12:09 I'm working on logging support with boost log right now
kylehuff 12:09 ah, my bad - I have not checked out 1.2.2 yet..
taxilian 12:09 np =]
the issues fixed in 1.2.2 are really very minor; most people didn't notice them
but I wanted to have them fixed in 1.2.x
since 1.3 has more changes and may be another two weeks
though I'm hoping to have it ready next week
logging will be one of the big features, it looks like
because I need it, so I'm writing it =]
amackera 12:09 necessity is the mother of invention, as they say
taxilian 12:09 yep
of course, they also say things like "so's your mama" a lot, and I'm not sure that really means anything
amackera 12:09 that's what she said!
har har har
taxilian: is it possible to call NPN functions from a different thread than the plugin was created on?
i know NPAPI doesn't like it
but is there a way in FB? i seem to remember something about that
taxilian 12:09 depends on the NPAPI function
and whether or not you're using the 1.3 release
amackera 12:09 NPN_InvalidateRect, and i'm on dev (so yes)
taxilian 12:09 no, that's the latest development copy
you can't call that until the actual 1.3 release
or maybe a few betas before that
amackera 12:09 it hasn't been implemented?
taxilian 12:09 … unless you want to implement that yourself, which will save me the trouble ;-)
it's planned, though
know how I'm going to do it
amackera 12:09 yeah sure, i can do it
taxilian 12:09 hehe
amackera 12:09 are there already implemented ones i can look at for sample style?
taxilian 12:09 let me show you what i'm trying to do
yes and no
here is the thing; I have an implemented way of calling Invoke
but I want to just make a way you can pass in a functor
so you can call *anything* on the main thread
and I figured out how to do it
but it's a little weird at first
amackera 12:09 sure
taxilian 12:09 trying to find where I put it...
hang on
amackera 12:09 k
taxilian 12:09
so it requires the BrowserHostPtr to be passed in
so it can verify if it is on the main thread or not
WarGloom 12:09 Did anybody try to compile examples on linux?
from current trunk
taxilian 12:09 WarGloom: yes, they built fine for me
have not actually run them, however
WarGloom 12:09 failed :(
taxilian 12:09 could it be a problem with WITH_SYSTEM_BOOST?
WarGloom 12:09 no, I tryed with default settings\
BrowserObjectAPI.h:18:2: warning: #warning "This header is deprecated - include JSObject.h instead."
FBTestPlugin/1.cpp:17:35: error: DOM/JSAPI_DOMDocument.h: No such file or directory
amackera 12:09 ahh
taxilian 12:09 1.cpp?
WarGloom 12:09 FBTestPlugin/1.cpp:23: error: cannot declare parameter ‘host’ to be of abstract type ‘FB::BrowserHost’
taxilian 12:09 you may want to check your tree for files that don't belong there
there is no 1.cpp
or shouldn't be
WarGloom 12:09 I didnot add it
taxilian 12:09 do hg status -u
WarGloom 12:09 how i can check this with hg?
taxilian 12:09 to remove any unknown files, hg status -u -n | xargs rm -v
amackera 12:09 ehhh be careful with that
taxilian 12:09 yes
do =]
amackera 12:09 haha
taxilian 12:09 <— no 1.cpp
WarGloom 12:09 oohh
taxilian 12:09 amackera: hg status -u -n | xargs rm -v -i
WarGloom 12:09 yes, you are right
taxilian 12:09 of course I am ;-) I am always right
WarGloom 12:09 :)
taxilian 12:09 however, in this case I cheated:
that built around midnight last night, a few hours after the last change to trunk
so I know it builds on linux =] this one is 64 bit
cygmatic: I doubled the sizes of the download yeterday. are ya proud of me? =]
WarGloom 13:09 :)) did you make breaking changes? I caught error: cannot declare parameter ‘o’ to be of abstract type ‘FB::JSObject’
taxilian 13:09 yes, if you're on 1.3 beta
FB::JSObject should be changed to JSObjectPtr
cygmatic 13:09 taxilian, euh.... totally ^^
taxilian 13:09 I keep considering pulling boost out of the repo, since without it's only, like, 400k, but people keep saying that they like having it there (6 survey responses so far, all say "keep it")
cygmatic 13:09 interesting
i guess it is too convenient
taxilian 13:09 might be worth making another download that doesn't have it, though, for those who have their own copy
considering it
WarGloom 13:09 it is important to save posibility to bould firebreath with system boost
taxilian 13:09 I agree
I think I have done that
let me know if it's broken =]
and help me fix it
WarGloom 13:09 ok! :)
taxilian 13:09 btw, cygmatic: if you'd like to see the results of the survey (so far) you can sign in at and you should be able to see it
WarGloom 13:09 may it's time to fix wiki for classJSAPIAuto "
Updated Sep 24 (6 days ago) by bignikita
Labels: Documentation
JSAPIAuto provides convenience facilities for writing scriptable objects.
Basic usage
Read-only properties
Read-write properties
Supported types
Catching basic types
Catching containers
Catching associative containers
Catching objects
Catching a variable number of arguments
Returning basic types
Returning containers
Returning objects
Callbacks from Scripts
While JSAPI and JSAPISimple provide all you need to implement scriptable classes, you might get annoyed by the amount of code needed for converting the data that comes in from JavaScript? - thats where JSAPIAuto comes to the rescue.
Consider adding a simple method to your class that adds two numbers:
FB::variant add(const FB::VariantList& values)
if(values.size() != 2)
throw FB::script_error("wrong number of arguments");
try {
long a = values[0].convert_cast<long>();
long b = values[0].convert_cast<long>();
return a+b;
} catch(FB::variant::bad_cast& e) {
taxilian 13:09 lol. never paste in an IRC room =]
WarGloom 13:09 throw FB::script_error("conversion failed :(");
Thats quite verbose and annoying to do in every method. JSAPIAuto allows you the following instead:
long add(long a, long b)
return a+b;
That is made possible by introducing helper functions for methods and properties, FB::make_method() and FB::make_property() that you use when registering:
registerMethod("add", FB::make_method(this, &MyClass::add));
make_method() inspects the arguments your methods expect and generates the neccessary code for conversion and checking the argument count.
Basic usage
To make your class scriptable with JSAPIAuto, derive from it and register your methods and properties, e.g. in the constructor:
class MyObject : public FB::JSAPIAuto
std::string m_message;
registerMethod("add", FB::make_method(this, &MyObject::add));
kylehuff 13:09 aghh! my eyes...
WarGloom 13:09 }
long add(long a, long b) { return a+b; }
void setMessage(const std::string& s) { m_message = s; }
std::string getMessage() const { return m_message; }
For property registration, combine registerProperty() with make_property().
make_property() supports two forms of properties:
Read-only properties
make_property(this, &MyClass::getter), where getter is a function that takes no arguments and returns a type that `FB::variant` can be constructed from.
Read-write properties
make_property(this, &MyClass::getter, &MyClass::setter), where getter is of the same form as before and setter is a function that takes one argument that FB::variant can convert to and has a return type of void.
Supported types
For property functions, the same types are supported as for methods - except that property setters can only take one argument and getters none.
For method registration, combine registerMethod() with make_method(), which takes a pointer to the class' instance as its first argument and a pointer to a class method as its second.
The argument types the member function expects will be discovered at compile time and code be generated that checks the number of arguments and tries to convert the FB::variant arguments to the argument types the function expects.
Catching basic types
Most basic types (numeric, string, bool) are already supported through FB::variants convert cast:
std::string MyAPI::test(long l, double d, const std::string& s, bool b)
std::ostringstream os;
os << "got " << l << ", " << d << ", '" << s << "', " << b;
return os.str();
Catching containers
To receive arrays from JavaScript? you can either use FB::VariantList as the arguments type or directly any STL-style container with the value-type of choice.
Take for example the following JavaScript?-call: Array(1, "2", 3.0));
We can catch the argument either as a variant array:
bool foo(const FB::VariantList& array);
Alternatively we can try to catch it as a container of strings:
bool foo(const std::vector<std::string>& array);
kylehuff 13:09 sorry WarGloom; gotta mute you until your client decides to stop trying to re-write the universe...
WarGloom 13:09 Catching associative containers
taxilian 13:09 sorry, I wasn't oped for some reason
welcome back =]
lesson learned? ;-)
amackera 13:09 lol
WarGloom 13:09 aha...
amackera 13:09 use next time
WarGloom 13:09 i wont to past only ONE line!! :(
taxilian 13:09 happens =]
no worries
cygmatic 13:09 i had a similar problem that everything before the line break wasn't visible for me ^^
amackera 13:09 irssi actually asks you before pasting on multi-line pastes
WarGloom 13:09 I promise i will be careful :)
next time
taxilian 13:09 no worries
I promise to kick you faster if you're not
next itme
WarGloom 13:09 ))))
kylehuff 13:09 lol
nitrogenycs 13:09 haha nice paste mayhem xD
happened to me once too, fortunately just 5 lines or so
taxilian 13:09 WarGloom: better? I updated the wiki. let me know if I missed something
WarGloom 13:09 yes, much better
taxilian 13:09 So in response to a comment made, I think I will loosen/clarify the contribution policy; we will accept patches, we'd just rather get them from a clone, particularly if it is at all significant =]
I'll have to update the wiki and such on that
WarGloom 13:09 i change in wiki JSObject -> JSObjectPtr
taxilian 13:09 thx
though that raises a question
that won't be the case in stable until 1.3 is released
maybe we should leave it until then
cygmatic 13:09 yes, please don't until 1.3 :)
i think after 1.3 we should try to keep the interface mostly stable again
most cleanup should be done with it
taxilian 13:09 I agree
which means if there is anything else that needs to be changed, tell us now =]
ok question for the group; where should the default logfile location be?
on each platform
and on non-windows, should I default to syslog?
WarGloom 13:09 linux syslog or .xsession-errors?
kylehuff 13:09 these are what kind of errors?
from the plugin?
taxilian 13:09 these are not just errors
these are general log messages
what level will be configurable
kylehuff 13:09 i see
taxilian 13:09 and you can either use the plugin's logging mechanism or your own
kylehuff 13:09 syslog is (or *should* be) reserved for system related error/debug reporting
non-system level applications should not dump to syslog
taxilian 13:09 as I just clarified to WarGloom, this will be configurable
I'm just looking for defaults
kylehuff 13:09 right, and I am saying, it should not default to syslog
=c )
taxilian 13:09 also, we could have different defaults depending on whether it is DEBUG or not
vote noted =]
what do you recommend? /tmp/project.log?
just trying to find a sensible default
WarGloom 13:09 ~/.xsession-errors
taxilian 13:09 hmm. I don't think I can add to someone else's logfile
WarGloom 13:09 I don't know what will be better for mac os
kylehuff 13:09 that is a good question, and I don't have a good answer..
cygmatic 13:09 on mac syslog would be a good default
kylehuff 13:09 /tmp/.something would probably be the safest bet - less likely to piss linux zealots off if someone releases a plugin with debugging left on...
taxilian 13:09 I suspect we'll need to fiddle with it some
by default I'll probably just force logging off when NDEBUG
but of course that will be configurable
some one a by-project basis, other will have to be configured globally
welll, I gotta go grab some lunch
be back later
cygmatic 14:09 taxilian, you've got mail from softpedia too?
taxilian 14:09 softpedia?
not that I know of
cygmatic 14:09 forwarded it
taxilian 14:09 cool
interesting that they found your email and not mine
cygmatic 14:09 hm, maybe because of me using mostly my real name?
taxilian 14:09 huh
cygmatic 14:09 ah well, who knows :)
taxilian 14:09 seems strange that anyone wouldn't know my real name by now; I'm not exactly quiet about it =]
cygmatic 14:09 as for the timer subject - it would make sense to invalidate all timers from the browserhost when it goes down?
taxilian 14:09 seems fair
cygmatic 14:09 what resolution do we need?
taxilian 14:09 millisecond?
I doubt we'd be accurate at microsecond
cygmatic 14:09 well, WM_TIMER e.g. doesn't go below 10 ms afair
taxilian 14:09 huh. guess we're stuck with that limitation, then; I think it'd be better to document that and possibly throw an exception if they try to do less than that
rather than decrease the resolution
oh, crap; I'm late for class. gotta run!
cygmatic 14:09 see you later
taxilian 14:09 ok, I'm back. :-P
I love wireless on campus
cygmatic 14:09 that was a short class ^^
taxilian 14:09 hehe
no, I just multitask
I'm in class
cygmatic 14:09 ah, ok *g
taxilian 14:09 welcome, gromps
grompy 14:09 Thanks Taxilian
cygmatic 15:09 taxilian: looking at several sources i'm even thinking CreateWaitableTimer()
e.g. the facts here are interesting:
taxilian 15:09 whatever looks like the best way to do it
nitrogenycs 15:09 I support the views of the virtual dub guy
Never use windows timers if you want good timing control
taxilian 15:09 does WaitableTimer run on the same thread, or does it create a new one?
cygmatic 15:09 yep, it does block :/
taxilian 15:09 so it has to be a seperate thread
cygmatic 15:09 damn, running a horde of threads just for precise timers isn't what i want
nitrogenycs 15:09 ehehe
taxilian 15:09 maybe we could support both options?
nitrogenycs 15:09 you could run some kind of scheduler thread. but if one of the scheduled things takes too long to execute, it gets bad
cygmatic 15:09 exactly, and pushing from there to the main thread would make that precision point a bit moot, wouldn't it?
nitrogenycs 15:09 plus you also might not want to run the user's code in an arbitrary thread
users might not be expecting their code to run in some kind of thread
cygmatic 15:09 well, maybe i'll just start with imprecise timers for now and we might add high precision ones later if needed?
taxilian 15:09 yeah, though we are planning to add thread synchronization stuff for cross-thread calls; however, that will use the windows message loop and thus not be very accurate
sounds fair
amackera: did you look at the cross-thread stuff at all?
nitrogenycs 15:09 as long as the user only calls back into fb code, then the threads are fine. If he calls some kind of other code (his own, a library, ...) it needs to be threadsafe. Which very few code is.
taxilian 15:09 granted, if it does create another thread, that has to be *very very clear*
cygmatic 15:09 nitrogenycs, it sounds like you've messed with timers a bit?
nitrogenycs 15:09 a lot :)
I did some of those timings myself
the resolution was a lot worse under 95/98, NT based kernels made it better
cygmatic 15:09 ah, i'd be glad to hear critical input then if i mess something up :)
nitrogenycs 15:09 :) not sure I am really qualified. I have the luxury to run my own main loop where I can just use QueryPerformanceCounter.
cygmatic 15:09 ok, but you might see some intricacies i simply hadn't to deal with yet
nitrogenycs 15:09 ok
I seem to recall some higher resolution WaitForEvent thing, I am currently looking for it. I can't really remember anymore.
Getting old xD
amackera 15:09 taxilian: I checked it out but I am a little confused
cygmatic 15:09 ah yes, the memories, the pain in the back and the hair falling out ^^
amackera 15:09 taxilian: I decided I'll just try messing with TimerQueueTimers to try and set up a timer without a HWND
instead of using my own sleepy thread
taxilian 15:09 amackera: yeah, I don't blame you
I'll get it working
cygmatic 15:09 amackera: wait, are we both doing timers now? ^^
nitrogenycs 15:09 cygmatic: sorry, can't find the high resolution version atm. Maybe there isn't one and I misremembered...
cygmatic 15:09 no problem
taxilian, what do you think where a TimerManager class with platform specific implementations belongs?
taxilian 15:09 hmm
I want to say ScriptingCore, but that might not really be the best place
perhaps PluginCommon
well, no
that is a very good question
probably ScriptingCore is the best place we currently have for it
nitrogenycs 15:09 what exactly are you using the timers for? just a generic cross-platform timer implementation or is it tied to the browser somehow?
cygmatic 15:09 #1 it is
plus it would cancel all timers when browserhost is going down
nitrogenycs 15:09 Are you aware of ?
I am not sure about the precision
cygmatic 15:09 yes, but that depends on at least boost system
i stopped looking after that :)
nitrogenycs 15:09 ok
taxilian 16:09 we're trying to avoid having absolute dependencies on boost where possible
binaries, anyway
though I do wonder if we haven't reached the point where that is pointless; I don't think boost system is all that big, it's only a couple of .cpp files
20K in cpp files
man, this logging stuff is taking way longer than it should
and IMO the boost log stuff isn't very well documented
though there are docs
cygmatic 16:09 ok, but do we need boost::system anywhere else? just for the timers would really seem like overkill
taxilian 16:09 I don't know
grompy 16:09 Anyone know the precision of the boost timers?
taxilian 16:09 no; however, from looking around a bit, I think boost timers use a seperate thread as well
and didn't we decide that was a bad idea for now?
grompy: I finally found something I wish I could steal from Move
some days I hate C++; often I'm working wtih boost when that happens
cygmatic 16:09 what is annoying you?
taxilian 16:09 trying to figure out how to make a asynchronous text sink for boost log
cygmatic 16:09 and we thought earlier that seperate threads wouldn't work well for high-precision timers due to not knowing how to reschedule to the main thread efficiently
taxilian 16:09 and I'm getting c:\lcode\firebreath-dev\src\3rdparty\boost\boost\smart_ptr\shared_ptr.hpp(378): error C2440: '<function-style-cast>' : cannot convert from 'boost::shared_ptr<T>' to 'boost::shared_ptr<T>'
cygmatic 16:09 that by itself is not very informative
nitrogenycs 16:09 does it give you a definition of the Ts?
cygmatic 16:09 it should in the error message
... blablah... [with T=X, U=Y, ...]
but that looks like the problem is actually something else
taxilian 16:09 hang on
sorry, was helping someone at school
yeah, I think this just only allows synchronous initialization this way
this is really really annoying
cygmatic 17:09 ok, i think i'd need to dig into boost::log to get that
taxilian 17:09 yeah
they show you how to create an asynchronous sink
then they show you how to do all this cool stuff with the logging
but it uses a synchronous sink, and it uses a helper to get it set up
but that helper doesn't exist for async, and they don't show you how to do that wihtout the helper
cygmatic 17:09 huh
taxilian 17:09 well, headed home. be back in a bit
taxilian 18:09 cygmatic: if we just link to a logging library and it is LGPL we should still be okay, no?
wait, found one licensed under apache
I'm using it
I just wasted way too many hours trying to get boost log working
my verdict: not worth it
kalev: you around?