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

IRC Nick Time (GMT-7) Message
FB_GitHubBot 00:12 FireBreath: master Richard Bateman * 85a9f1f (2 files in 2 dirs): Fixed HttpService build errors from recent refactor - http://bit.ly/ej6Rwr
jtojanen 06:12 Seems that WITH_SYSTEM_BOOST all the unit test fail to build as boost-date_time is missing
Taxilian, could you add "add_boost_library(date_time)" to root CMakeLists.txt ?
WarGloom 07:12 what firebreath version do you use?
jshanab 09:12 I am having an issue coping files in cmake custom command. It works on command line but when the command is cmake.exe -E copy, it fails. Are there some tricks?
taxilian 09:12 hmm
none that I know of; it's always worked for me
if anyone sees jtojanen come back and ask about the date_time stuff, I'm not going to add that as a general dependency to the full project because only system boost needs it and when system boost is configured properly it should do autolink
jshanab 09:12 can you pastbin me an exampole? I probaly got slashes or quotes screwed up
taxilian 09:12 we could maybe add it conditionally I suppose
I don't have an example at the moment; I've used it before, but am not using it currently. Why don't you pastebin me what you are doing?
jshanab 09:12 sure
http://pastebin.com/5iPN9ApF
MYLIB_SOURCE_DIR is just set above
the command is added to the project properly and shows up as
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E copy ../lib/libavcodec/bin/*.dll ../../build/projects/MVSArchivePlayer/Win32/dlls
if errorlevel 1 goto VCReportError
Ah...I bet the copy is at the level of the solution?
Which is not known to build :-)
taxilian 09:12 that could very possibly be
change it to use absolute paths, it might fix the issue
do you know how to convert to an absolute path in cmake?
jshanab 09:12 Maybe, just using the ${CMAKE_CURRENT_SOURCE_DIR } looks like progress
taxilian 09:12 that should be absolute, so that should work
jshanab 09:12 yeah and the path is perfect, but it doesn't work :-(
taxilian 09:12 so your cmake command is now using absolute paths on both sides?
jshanab 09:12 absolute, but with a few ../../ in the middle, i wonder if those are not allowed
taxilian 09:12 guess it's possible that visual studio gets confused on them
or maybe you can't use / when calling cmake command line
jshanab 09:12 I am taking the resulting command from the properties and and running it on the command line, it also fails so there is still hope
taxilian 09:12 =]
aye half faythe inn ewe
jshanab 09:12 *.dll is ot allowed ?
"that the
> use of wildcards is not possible in this command"
taxilian 09:12 that could easily be
jshanab 09:12 That is a quote from a blog :-( It is a feature request though
taxilian 09:12 you could always copy the directory they reside in
jshanab 09:12 !
taxilian 09:12 or write an actual cmake script (I think you use it with -P) that does a GLOB and copies each one
or for that matter if you know you're on windows, you could just use the copy command
jshanab 09:12 yeah, I tried that, I'll try that again
I suppose I could just add 5 custom post build commands
taxilian 09:12 lol. yeah, I guess that'd work
kalev 09:12 my amazing contribution of the month (removing a comment) is incoming
FB_GitHubBot 09:12 FireBreath: master Kalev Lember * 844ed50 (1 files in 1 dirs): PluginWindowX11: Removed an obviously incorrect comment ... - http://bit.ly/e9xY8a
taxilian 09:12 lol
well done, well done!
kalev 09:12 thank you sir!
taxilian 09:12 yeah, not sure how that one slipped by me, but you're right; all variables should be initialized
kalev: WarGloom has run into a linux bug where if he refreshes the page a whole bunch of times right in a row, the browser crashes
have you seen this issue?
FB_GitHubBot 09:12 FireBreath: master Nikita Bige * db05fa3 (6 files in 1 dirs): add array test, add javascript async dialog test
FireBreath: master Richard Bateman * ff17a45 (5 files in 2 dirs): Fixed some issues in recently added FBTestPlugin test and also fixed a bug in cross-thread Invoke exception handling
FireBreath: master commits 844ed50...ff17a45 - http://bit.ly/eCMMKE
taxilian 09:12 that's on FBTestPlugin, aparently
kalev 09:12 I haven't, but then again I haven't tested latest code much
taxilian 09:12 it's failing to lock a recursive mutex
which completely baffles me
kalev 09:12 what mutex where?
taxilian 09:12 the mutex on PluginEventSource::SendEvent
kalev 09:12 oh, the weak_ptr using in there is nice, gave me a good idea for my own code
taxilian 09:12 thanks =] I liked the way it turned out
much better than the previous way we did things
weak_ptr is a really nice tool for FireBreath
kalev 10:12 no idea what might go wrong with locking in there
taxilian 10:12 nor I
here is the stack trace: http://fpaste.org/ON5w/
btw, while I'm doing refactoring, can anyone think of anything I haven't addressed that should be refactored?
My current frustration is the way the pluginwindow and platform specific npapiplugins still have to be in PluginAuto (was PluginCommon) :-( I'm not sure how to get around this, though
NoAntzWk 10:12 Hi richard!
I think that the problem is inMap["foo2"].
The compiler returns an error trying to access to JSObjectPtr via operator [].
taxilian 10:12 hey
inMap shouldn't be a JSObjectPtr if you're going to try to use it that way
so a Javascript object can be automatically converted to a std::map
in my example the parameter is a std::map<std::string, FB::JSObjectPtr>
so inMap should be that type
and inMap["foo2"] should be a FB::JSObjectPTr
NoAntzWk: sorry, I was outside shoveling snow when you popped in =]
NoAntzWk 11:12 Hi.
mmh... inMap["foo2]->GetProperty(...) fails: error C2678: binary '[' : no operator found which takes a left-hand operand of type 'const std::map<_Kty,_Ty>' (or there is no acceptable conversion)
inMap["foo2"]->... sorry
taxilian 11:12 are you doing inMap["foo2] or inMap["foo2"]?
NoAntzWk 11:12 no, no.... inMap["foo2"]->GetProperty(...) I have a mistake writting.... :)
taxilian 11:12 hehe. hang on, let me try it =]
hmm. maybe something has been changed since I last did this… the example in FBTestPlugin has been changed to a different syntax
well, that'll work for you for now. go look at FBTestPluginAPI.cpp on line 173
NoAntzWk 11:12 which commit? from master branch?
taxilian 11:12 that's an example of one way to convert it to a std::map
yeah
master
I always work off of master
that way if there are any issues they are found
I'm in the middle of reworking how the conversion works for variant, so I'm not at a point where my workspace is buildable =]
jshanab 15:12 My pluging slowed down to "unusable" so i ran a profiler. Most of the time is spent in towstring, a unicode thing. Is unicode just that bad?
taxilian 15:12 not usually; what is calling towstring?
jshanab 15:12 log4cplus for one
but any <<
taxilian 15:12 really? weird;
how much logging are you doing?
jshanab 15:12 not much now, but it is using the CPU anyway. I think the << operators run anyway :-(
but it is like 51% logging and 49.99% of that 50 is in towstring
taxilian 15:12 if you use a macro to do the logging you can disable it so it doesn't run at all
jshanab 15:12 do I even wnat or need unicode?
taxilian 15:12 not if you're only doing english
jshanab 15:12 The lib in firebreath is Unicode, right?
taxilian 15:12 yes
one thing you could do is to change all your strings to wide strings
that would preserve unicode support but remove the need to convert string to wstring
if it were me, though, I would figure out why so much logging is going on
and reduce it
because that's your real problem
jshanab 15:12 ah, I thought the macro was doing that, instead it is converting on the fly?
taxilian 15:12 how are you calling log?
jshanab 15:12 LOG4CPLUS_DEBUG(logger_, LOG4CPLUS_TEXT etc,etc
taxilian 15:12 well, sounds like the macro is convering to wstring at runtime; you can fix that in part by using L"string" instead of "string"
jshanab 15:12 So I need to eliminate all the LOG4CPLUS_TEXT and make sure all << "foo" are already unicode?
taxilian 15:12 that would be one way to reduce those calls, yes
jshanab 15:12 is L"string" cross platform?
taxilian 15:12 but I still say that's not the real problem =]
yes
jshanab 15:12 why, what do you think the real problem is? WTM logging?
taxilian 15:12 too much logging
you are setting the log level, I assume? http://log4cplus.sourceforge.net/loglevel.html
jshanab 15:12 yes, i am
taxilian 15:12 either way that's not a bad optimization, to use unicode strings
jshanab 15:12 I think maybe my wrapper macro is causing multiple copnversions and it is converting even when not up to level
taxilian 15:12 but that just seems like an awful lot of logging if it's using that much CPU anyway
jshanab 15:12 Yeah, weird. Also i am using a pattern layout appender, it claimed no penalty for it's use, but I wonder
taxilian 15:12 dunno
I haven't done all that much with logging yet, so I'm no expert
jshanab 15:12 yet :-)
taxilian 15:12 =]
that's the one thing that kinda stinks about running a project like this.. the sheer scope of things that people expect you to know everything about is a little on the ridiculous side :-P
on the other hand, that also makes it look really good on a resume… =]
jshanab 15:12 Ther ya go
the silver lining
taxilian 15:12 http://www.despair.com/pes24x30prin.html
jshanab 15:12 :-)
taxilian 17:12 getting close to having a refactor of JSAPI that will allow users to create their own conversion functions
i.e. so you can convert_cast<…> to your own type
also you can convert_cast<YourPluginAPI> and it should work as well, assuming that's what is in it
taxilian 17:12 in fact, I think it's working
taxilian 18:12 gah!!! I hate GCC! <grumbles>
taxilian 20:12 I have defeated GCC! I win!
not many people around for the holidays :-P
FB_GitHubBot 20:12 FireBreath: master Richard Bateman * 1af4e14 (13 files in 5 dirs): BREAKING CHG! Major FB::variant refactor, minor behavior change ... - http://bit.ly/h8FAMD