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

IRC Nick Time (GMT-7) Message
WarGloom 00:12 do you know why firefox, chrome, chromium crash if replace plugin file while browser is open?
taxilian 00:12 on what platform? linux?
WarGloom 00:12 yes
taxilian 00:12 well, I could speculate
what happens if you just delete it?
WarGloom 00:12 hm, one moment
more info: падают они при закрытии
taxilian 00:12 when you delete it?
WarGloom 00:12 no crash
taxilian 00:12 interesting. That's what happens on Windows if you move the file while it's being used
well, general rule of thumb is that you should never replace a plugin file while it is being used; instead, put another file in place of it with the same metadata but a newer modified date
firefox *should* see that as the most current version
WarGloom 00:12 I think only windows version have this problem
taxilian 00:12 which problem?
not replacing a file while used? in general, yes… but in this case, it would seem that you have the problem too, for whatever reason
probably the browser is scanning the directory again and expects that to still be the same file
WarGloom 00:12 I think browser scan plugin directory once while starting
taxilian 00:12 no, it scans it more than that
WarGloom 00:12 and if settings changed
taxilian 00:12 because if you refresh the page it will detect new plugins
WarGloom 00:12 hm
taxilian 00:12 I don't know the details of how it works on linux as well as I do on Windows, so I could be wrong.. but my experience has always been (on both Windows and Mac) that the best practice is to just either make sure the browsers are closed or use a different filename — usually one with the version in the filename
WarGloom 00:12 so, may be the default output plugin name should be changed and containg at minimum version number ?
taxilian 00:12 I have considered it, but everyone does versioning a little different
I decided that's more the responsibility of the install script
WarGloom 00:12 I saw Iain Collins article... but it is closed for unregistered users
taxilian 00:12 yeah, we should move that
he put it in his personal space because he doesn't consider it ready
but really, that's what a wiki is… docs aren't completely ready, but you put what you have up
if people don't like 'em, they fix 'em =]
WarGloom 00:12 :)
taxilian 00:12 WarGloom, kalev: do you guys (preferably both, but one will suffice) have a minute to do a quick test of the master branch at [email protected]/taxilian/FireBreath ?
WarGloom 00:12 yes
taxilian 00:12 I have verified that it builds, but I don't have an easy way to do a functional test
also the bug you noticed this morning (yesterday?) should be fixed (echo should work)
WarGloom 00:12 firefox echo test passed
and on my yesterday test failed with uncaught exception: Could not convert from St6vectorIN2FB7variantESaIS1_EE to N5boost10shared_ptrIN2FB8JSObjectEEE
taxilian 00:12 yeah, that one I haven't decided what to do wtih
see, it's not really a bug per se
because you're just getting what was actually passed back
that is, a FB::VariantList
it doesn't go through the browser because it's an actual JSAPI object
WarGloom 00:12 but in 1.3 it was JSAPIobject
taxilian 00:12 that's because in 1.3 we sent those calls through the browser
but that caused one of the crashes you were seeing
we fixed that the other day and caused this issue
hence I haven't decided what to do with it yet =]
WarGloom 00:12 I can change my code... but we should add note about it to documentation and breaking change list
taxilian 00:12 yeah
in some ways I'd like to just make it so that it could work as either
but if you do it as a FB::VariantList then it will always work in that case
I'm really not sure what I want to do about it
not sure what the best solution is
it's kinda a weird edge case
WarGloom 00:12 %)
taxilian 00:12 this release has turned into one where there are some little breaking changes
nothing really serious
but enough to be annoying :-(
however, they really do need to be fixed
WarGloom 00:12 with get_jsapi function I think that I will change part of my code to work directly with someObjectAPI
taxilian 00:12 yeah; I'm hoping to update it to build that into the conversion stuff
but I need to refactor the conversion stuff first
see, I'm just getting started on this refactoring :-P
ActiveXPlugin needs a lot of work
and the variant conversion stuff needs to be extensible
WarGloom 00:12 greate I changed test to work with FB::VariantList and test was passed
yes, firefox and chromium passed the tests
taxilian 00:12 excelent
we are making progress =]
the nice(scary?) thing about the way that works is that you could pass back types that aren't known to the browser and it will work
since it's not going through the browser
any arbitrary type :-P
I do still need to update the IE stuff to work the same way, however
WarGloom 00:12 not sure that i understand you correctly
"you could pass back types that aren't known to the browser"
taxilian 01:12 well, FB::variant can actually store *any* type
you can make up your own type and store it in a variant
it's just when it hits the browser layer the conversion tool doesn't know what to do with it
however, since your code would know what to do with it, you could pass that type back and it would only be usable to your own plugin
so if it returned a WarGloom::WeirdType(true), the caller could just do res.cast<WarGloom::WeirdType>() and get it out
since it doesn't go through the browser
WarGloom 01:12 aa,, what will hapen if someone call from JS this method wich return such type?
taxilian 01:12 I think you'll get undefined, if I remember correctly
WarGloom 01:12 I will experiment with this feature
taxilian 01:12 hehe. it's always entertaining when we get accidental free features
one thing to know is that I may change it so that you can't pass unknown types without an additional parameter
just to make sure you do it on purpose
and not on accident
but I'll tell you what that is when I decide
WarGloom 01:12 ;-)
taxilian 01:12 I have some neat plans for varant, but I'm not sure yet if I can pull them off
it'll require some interesting template magic
I really want to do that tomorrow, but there are some other things I should maybe do instead :-/
if all goes well, though, you will be able to use boost::shared_ptr<YourPluginAPI> as a parameter type
FB_GitHubBot 01:12 FireBreath: master Richard Bateman * 7d7c9b7 (63 files in 25 dirs): Major refactor of project structure, part one. Removed PluginWindow project, moved ...
FireBreath: master Richard Bateman * 9a3bdec (3 files in 2 dirs): Implemented JSAPI pass-through for IDispatchAPI
FireBreath: master commits 06674cd...9a3bdec -
taxilian 01:12 now *that* is a change message...
WarGloom 01:12 what about "Exception: TypeError: Cannot convert object to primitive value" when trying console.log(pluginObject);
taxilian 01:12 console.log probably just doesn't know how to deal with that type of object
doubt there is anything we can do about it
if you wanted to play, you could watch the entrypoints and see what members it queries for
if you implement those properties, it might work
WarGloom 01:12 wait a moment but this code worked before !
taxilian 01:12 hmm
what did it do?
WarGloom 01:12 it is completely worked and show what toString returned
короче, я так отлаживался и определенно такой код должен срабатывать
taxilian 01:12 hmm. well, if it worked before it should still work
so let me see if I can reproduce it
then I really need to go to bed =]
WarGloom 01:12 you can add such call to console.log in test.html
taxilian 01:12 so just console.log(plugin())?
WarGloom 01:12 yes
var plugin = window.plugin();
taxilian 01:12 hmm. it works fine for me...
WarGloom 01:12 in chromium?
taxilian 01:12 what browser are you on?
I'll try chrome
WarGloom 01:12 yes firefox is worked
so I think this is bug in chromium
taxilian 01:12 well, let me see what I can do
WarGloom 01:12 and in google-chrome :(((
taxilian 01:12 interesting… it's looking for a "value-of"
sorry, valueOf
hmm, I think I know why
gimme a sec
WarGloom 01:12 i'll come back in 5 min
taxilian 01:12 good catch on this, btw
and fixed
FB_GitHubBot 01:12 FireBreath: master Richard Bateman * 8b16d9b (1 files in 1 dirs): Fixed toString so it doesn't return a function object like other members do (Chrome gets confused when it does) -
taxilian 01:12 ok, I'm headed to bed
let me know what else you find and I'll fix it in the morning
WarGloom 01:12 ok good night
taxilian 09:12 Good morning, all
jshanab 09:12 Mourning
taxilian 09:12 how're stuff?
that plugin still coming along okay?
jshanab 09:12 I had to stop on the plugin to get the back end it connects to stable, it is doing great now (plug for friggen awsome)
Today I get back on the plugin iif I can solve a weird bug, when i run my code as a service, log4cplus goes silent. no files, no erros, just nothing
taxilian 09:12 cool
hmm. I would guess that to be a permissions issue, given no further details than that
jshanab 09:12 I am, as you suggested(thankyou) using the static log4cplus from firebreath
taxilian 09:12 simply because a service usually runs in a different context
glad it helps =] I had to do a bit of work on the cmake project stuff for that… it actually came with one, but it only worked on windows
jshanab 09:12 First guess of mine two, I am able to write gigibytes of video and megabytes of index info from the same exe.
taxilian 09:12 lol. my son is walking around my office, he keeps picking up different things and acting like they are telephones. currently he has a wiimote nunchuck held to his ear and is happily chattering incoherently into it
(he's 18 months)
zmichl 09:12 Hi there. Can I share constants between JS and C++ using NPAPI?
taxilian 09:12 umm… depends on what you mean
you could expose properties from your JSAPI object that return the values of those constants
(that's a FireBreath npapi plugin; raw NPAPI it would be an NPObject)
zmichl: if you could be more specific on what you're trying to do, we could probably help you better
FB_GitHubBot 09:12 FireBreath: master Richard Bateman * df83d35 (8 files in 5 dirs): Renamed NpapiPlugin to NpapiCore, moved unit tests to tests/ -
zmichl 09:12 taxilian: Yes :) When using XPCOM, I can define constant in IDL file, generate XPT file and then access it from JS through Components.interfaces... So something like this.
taxilian 09:12 hmm. I'm not familiar with XPCOM much, since I started doing plugins about the time XPCOM was deprecated
but if you're just looking for something you can access like plugin().CONSTANT_NAME, that's not hard
I am of course biased, but if you're moving an XPCOM plugin to npruntime, my strong suggestion would be to move it to FireBreath at the same time; you'll thank me for it later
up to you, of course =]
zmichl 10:12 taxilian: yes, I'm moving from XPCOM and I'm using FB already, don't worry ;)
taxilian 10:12 well done, well done ;-)
if you use the latest dev branch, which hopefully will be hitting official beta soon (feature lock), it has a new "attributes" feature that makes it easy to do "constant" type attributes
attributes being like properties except it's just a variable instead of a getter and setter
you can register a read-only attribute for your constant
oh yeah, and make sure you fill out the survey if you haven't :-P
zmichl 10:12 Ok, thanks for info. I'll fill out the form soon ;)
taxilian 10:12 let us know if/when you need more help
taxilian 13:12 any time I forget how much I *don't* love ATL I find myself working on it and the memories just flood back
taxilian 14:12 scJohn: if you have a second sometime, could you try the latest trunk in VS Express? I think I've fixed all the issues that required any tweaking as well as removed the need to add lib and include dirs
scJohn 14:12 sure, was going to ask if you wanted me to test the latest updates
taxilian 14:12 though you still need to have the ddk installed in a normalish location
I have a VM with express on it now, but it's not on the computer I normally develop on
I think I did that Monday… I'm losing track :-P
I am also reading and considering your email, btw; I'll have a response soonish
scJohn 14:12 ok, how far back should I go, ie which part are you teting
k, thanks
taxilian 14:12 just general use; use the trunk with no changes and see if it works =]
scJohn 14:12 should i start a new project?
taxilian 14:12 you should even be able to remove the atl/mfc dirs (if you want to)
either way
shouldn't matter
scJohn 14:12 ok
taxilian 14:12 scJohn: see pm
jshanab 16:12 I am getting an erro r on calling prep because i moved some things. It says "...Does not match the source used to generate cache." can I delete the cache?
taxilian 16:12 yeah
delete the cache
that's normal if you move the build dir
just recreate it
that's why you don't want to modify things in the project by hand instead of with cmake =]
jshanab 16:12 thanks
taxilian 16:12 yw
jshanab 16:12 I hope i didn't screw things up. I deleted the cache and it still gives same error
taxilian 16:12 did you delete the whole build dir?
jshanab 16:12 no
taxilian 16:12 do so
jshanab 16:12 and it is bitching about a folder in build already existing :-)
taxilian 16:12 you never delete just part
jshanab 16:12 I have so many folders named "build" shucks
taxilian 16:12 lol
the build dir created by the prep script is completely disposable
jshanab 16:12 yeah, but I justdeleted one and it made no diff LOL
It is always at same level as project?
taxilian 16:12 what is your prep command?
what do you type?
jshanab 16:12 common\Firebreath\prep2010.cmd FirebreathPlugin
taxilian 16:12 then the build dir will be ./build
same place as the .sln file you (hopefully) open
rather the .sln is under the build dir
jshanab 16:12 ko, I think I got it, it is BUG
taxilian 16:12 lol. yes, the build dir gets big
it has all the intermediate binaries in it
jshanab 16:12 I haveben teaching Visual Studio to stop putting the #$##$#%$% build products in my source directories.
Need to do that for my FB project too
taxilian 16:12 it doesn't
build/ is not a source directory
jshanab 16:12 2.86 GB
taxilian 16:12 please, PLEASE don't think of it as a source directory
in fact, that's 1/2 of why we even have a build directory, is to keep all that crap out of the source directories =]
jshanab 16:12 right, but VS defaults to putting everthing right wher you are building. So I have a build dir like FB for my other products. The problem is that the build directory is at the same level as the projects and it is a subdir of source control, so I have to be carefull not to check it in, I need to specify it in my system wide build dir :-)
taxilian 16:12 you can put the FB build dir wherever you want
jshanab 16:12 Yeah. I forgot what I did a week or so ago. gotta reconnect signtool!
taxilian 16:12 that's why I keep telling you not to do that by hand in the vs project
do it in cmake
then it's done
jshanab 16:12 I am not sure what you mean, I am trying to do everything in CMAke by using the prep. I made a cmake custom target to do activex signing, for some reason moving it broke it. Just looking at it now
I am staying outside of vs, no worries
I had an issue with cmake not finding the signtool before, once it worked it worked over and over again, but the first time fails, something amiss in my search
taxilian 16:12 oh, okay
so it's the custom target that broke?
jshanab 16:12 Done. Windows update changed path name from 7.0 to 7.0A My cmake is written to stop if it can't find it
taxilian 16:12 you could use find_program to locate signtool
jshanab 16:12 I am, it needs paths
taxilian 16:12 yeah; you can make it pretty robust, but it takes some work
jshanab 16:12 (i didn't haowever claim i am using it correctly)
taxilian 16:12 I would have thought that signtool would be in the path, but I guess not
if you really want to see some fun code take a look at what I did to find ATL on VS Express sometime =]
jshanab 16:12 windows changes paths all the time, i think it is a "you should be using the registry" attitude with a lets make life difficult for those that don't kinda thing :-(
taxilian 16:12 hehe. well, you can actually use the registry if you know a key that tells you what you need
cmake supports registry lookup
jshanab 16:12 I was thnking about it, but that is the least of my worries :-)
taxilian 16:12 true
I usually work on frameworks, so it has to work everywhere
jshanab 16:12 I have made some major re-factorings. This is gonna blow
taxilian 16:12 lol
I'll trade you...
you can finish refactoring the ActiveX stuff… =]
jshanab 16:12 LOL Original code was writen for one and only one video format and lots of magic strings and if statements, I mad an interface and subclassed today but I am truly stuck on the #[email protected]#$ logger
taxilian 16:12 :-/
still better than ATL :-P
not to be competitive or anything =]
jshanab 16:12 better than MFC..."I am drowning in the whole goddam alphabit" --wargames 2
taxilian 16:12 lol
wow… the ActiveXCore project finally builds… now I just have to put everything back together
jshanab 16:12 Bad is when you realize that the code you inherited stores an hour worth of jpegs at 1 frame per second in memory of r it's player. It has been working for 1 fps. as we got for 1fps CIF to 30fpsH264, that would be more ram than I got!
When i decompress a H264 frame, it is raw, can't just store as jpeg and let windows decode it.
Where should I put a few dlls I need to have packaged when wix kicks off. I need them per platform so i had them in win32, but of course that goes byby
taxilian 16:12 lol
we haven't really formed any "best practices" for that
jshanab 16:12 wait, sorry, i have them in Win subdir and a copy target. Guess I messed up yet another path
taxilian 16:12 so put them wherever is convenient =]
that'll work =]
jshanab 16:12 They must be under build for them to package :-)
I think the copy is on the todo list. I am the custom target for now
taxilian 17:12 hehe. yeah, there is a lot with the install system that could probably stand to be improved now that it's been used a bit
it hasn't really been touched since January; I'm impressed it's working that well
jshanab 17:12 Works great. Would work better if I used an env var instead of ../common where I just moved it. pft
taxilian 17:12 lol
jshanab 17:12 The answer looks like the way I do on linux and on windows in my last job. An absolut top level build dir and then subdirs in it. Then use an env variable for that. only way to keep install scripts sane
taxilian 17:12 always fun
you could always just rework everything to use cmake, then you could have them all build to the same place ;-)
jshanab 17:12 I think I had better do this CMAKE stuff in the morning. I started with my own copy of the common directory in case i needed to change thinks, now i need to share with the other visual studio projects. I am not sure it will work having cmake and projects and solutions like this, may be best to keep my own copy
taxilian 17:12 gotta love refactoring, eh?
the good news is, I think I've just about got the activex refactor done; when finished there will only be 1 auto-generated helper project instead of three
though that doesn't help you with your probelm =]
FB_GitHubBot 23:12 FireBreath: master Richard Bateman * 31a6307 (17 files in 10 dirs): ActiveX refactor to ActiveXCore, ActiveXPlugin project merged into PluginAuto(was PluginCommon) ... -