IRC Log Viewer » #firebreath » 2012-08-15

IRC Nick Time (GMT-7) Message
Oscar 03:08 Hi guys. I am a Mac beginner and I wanna ask how to call a Cocoa API which is Objective-C in Firebreath's C++ file ?
taxilian 08:08 FireBreathBot: tell oscar if you make a .mm file you can put both objective c++ and regular c++ in it; search firebreath's codebase for .mm files for examples
FireBreathBot 08:08 taxilian: I'll pass that on when oscar is around.
Gordon_LN 09:08 FYI - I am up and running on the 1.7 base (and have now moved my outstanding pull request from 1.6 to 1.7).
Thx for help - IE 64bit issue ended up being a confused registry (I _think_) as a cleanup and reboot resolved it. The symptom was the JS attachEvent calls never ever made it into my DLLs dispatch handler (I think thats the correct terminology).
taxilian 09:08 Gordon_LN: why are you not using add_boost_library when with_system_boost?
also why are you always including date_time?
Gordon_LN 09:08 three add_boost_library's didn't work, it only ended up adding one of the libs.
taxilian 09:08 hmm. that doesn't make sense; add_boost_library should be bascially doing the same as the find_package
I'd rather fix add_boost_library rather than bypass it
bypassing it just hides a bug
ahh, I see the explanation in your comments
Gordon_LN 09:08 The date_time was being added already (if WITH_SYSTEM_BOOST was true) so I just included it. The regex is a bit suspect tho.
taxilian 09:08 hmm
so what about this;
why don't we make add_boost_library append the library to the list of boost libraries that are needed and then call find_package again with the new list each time?
I realize it's a bit redundant, but I would really like to have a consistent interface
Gordon_LN 09:08 I haven't looked at the "local" boost stuff - do you compile the required cpp files directly into the project?
taxilian 09:08 no, I compile them as static libraries
Gordon_LN 09:08 But you _do_ compile the cpp's yourself?
taxilian 09:08 correct
the goal being that those who don't generally use boost don't have to worry about figuring out how to build it and taking the time to install it, etc in order to use FireBreath
Gordon_LN 09:08 Which I can appreciate (just I am in the already using boost camp already). Question - your in the process of updating to 1.50 but will it still to continue to work with older versions?
taxilian 09:08 it should
the only thing that has changed in a breakable way is boost::filesystem
and we're not using that
at least not in core. I'm using it in my plugins =]
Gordon_LN 09:08 Yes - but at least Ver 3 is present in older (1.46) releases
taxilian 09:08 true
just not enabled by default
Gordon_LN 09:08 While I am new to the Linux/OSX world - you gotta like the whole apt-get and mac ports way of getting things like boost.
taxilian 09:08 yeah
do you think you could make that update to add_boost_library? or do I need to do that?
'cause if you can do that, I think I can accept your pull request today
Gordon_LN 09:08 ok - lemme take a look (changing cmake files is like messing with a genetic algorithm - every now and then you need to do something random and see if it makes it better!)
Jira + GitHub good idea or bad idea?
taxilian 09:08 lol. cmake isn't as bad once you get the hang of it, but I admit I'd dearly like to completely refactor the whole cmake mess in FireBreath
hmm; in what situation?
Gordon_LN 09:08 We are looking for a better "issue" tracker for our github work and I know you have Jira experience.
taxilian 10:08 I personally really like Jira
we use it at work as well
it's nice for open source projects because it's free
for business it's $10 / yr for up to 10 users, after that it gets expensive
so it just depends on what you need
Gordon_LN 10:08 Internally we were bugzilla, but since we went OSS we have been using github issues
taxilian 10:08 main downside is that it's a bit of a pain to maintain, upgrade, etc
probably less so if you are used to dealing with tomcat, though
Gordon_LN: let me just put it this way: the reason I use Jira for firebreath is that I hate it significantly less than almost all other issue management systems I've used
emicastro 10:08 Hi
taxilian 10:08 hello
Gordon_LN 10:08 (and thats the quote I will use!)
taxilian 10:08 =]
emicastro 10:08 taxilian: this key HKEY_CURRENT_USER\Software\MozillaPlugins is created by regsvr32 or by firebreath?
taxilian 10:08 emicastro: regsvr32 doesn't do anything by itself except call a particular entrypoint in firebreath
go look at gen_templates/*.rgs
emicastro 10:08 ok
NoRemove this some sintax that I don't know... How can I google it that?
registry sintax? o_O
taxilian 10:08 heh. I have never found a good reference for that file format
it's an ATL registry tool
I figured it out by walking through the parser code
emicastro 10:08 :) ok... when I do the unregistration the key HKEY_CURRENT_USER\Software\MozillaPlugins will be remove?
taxilian 10:08 anything not marked NoRemove will be, yes
emicastro 10:08 ok, I the millon dollar question... why HKEY_CURRENT_USER\Software\MozillaPlugins is mark as NoRemove? :)
taxilian 10:08 oh, sorry, misread
because that's not our key
it belongs to mozilla
we should remove our key from inside it, but not that key
emicastro 10:08 but are we removing this key from HKEY_CURRENT_USER\Software\MozillaPlugins ?
I mean... into HKEY_CURRENT_USER\Software\MozillaPlugins we are generating a new entry <myplugin> for example, and when we unregister our plugin, the entry HKEY_CURRENT_USER\Software\MozillaPlugins\<myplugin> is still there
taxilian 10:08 that should not be still there
emicastro 10:08 you mean when the unregistration is done? or... that this entry has never should be there?
taxilian 10:08 when the unreg is done
emicastro 10:08 mmm in my FBControl.rgs should be the code that remove that entry right?
taxilian 10:08 well, sorta. it's not actually code that removes it, it's just a description of what should be there and there should be no NoRemove on the actual plugin key
emicastro 10:08 could you explain to me the code in the 71 line of FBControl.rgs....
taxilian 10:08 can you send me a link from github? I'm really swamped today
emicastro 10:08 and the 2 lines that follow
taxilian 10:08 says create a key MozillaPlugins if it doesn't exist; when you uninstall leave it
the line below says create a key inside that called (mozilla plugin ID), force remove it on uninstall
emicastro 10:08 so this line will remove the key that I was talking
taxilian 10:08 it should, yes
rather it should cause it to be removed
emicastro 10:08 ok, I will debug more and try to figure out why this key still there when I run the "regsvr32 /u" :S
taxilian 10:08 it's possible to run regsvr32 in the debugger and set a breakpoint in DllUnregisterServer
then step through the code to see what is happening
tedious, but I've had to do it many times
emicastro 10:08 mm I a little suspisous about one thing... My installer run with high privileges when is running... and the execution of the regsvr32 is done with this kind of privileges... Could this produce some kind of problem?
taxilian 10:08 potentially; if you're installing to HKCU with elevated privileges it may try to register everything in the wrong place
if you're using an elevated privilege installer you'd be better off making your installer per-machine
emicastro 10:08 ok... But I've look the next! Very strange... I'm installing the x64.dll and then the x86.dll (we talked yersterday about that)
when I uninstall I run the regsvr32 /u x86.ll first... and then the x64.dll
and what is happening is that when I run the first uninstall command, the key is removed
and when the regsvr32 /u x64.dll is executed, the key is created, on unireg process
mmm It's not about this combo... It's about registering two dll identically (one per 64 and one per 32 bits)
If I register the 32 bits, and then unreg. then the key is created and removed perfectly...
the same with the x64.dll
but the problem is when I have the two registered at the same time
taxilian 10:08 no idea
emicastro 12:08 where are the definition of this vars ACTIVEX_PROGID, PROGID, CUR_GUID,FBSTRING_FileDescription, etc
Gordon_LN_ 12:08 I am not sure how possible it will be to use find_package(boost) if you want the plugin projects be able to "add" items to it.
taxilian 12:08 scoping should take care of itself
emicastro all of those things are defined in PluginConfig.cmake
Gordon_LN_ 12:08 It needs to be calculated before the subdirectories are parsed...
taxilian 12:08 Gordon_LN_ it certainly is; however, if you run it again it should override the previous case
so if you just run it each time then the last time it runs should have all needed pieces
that's my theory, anyway
Gordon_LN_ 12:08 No - it won't run again... You need to delete the Boost_* cache before its re-calculated.
taxilian 12:08 if that's not the case then we have an even bigger problem: what if they need more libraries than that?
Gordon_LN_ 12:08 IMO - I would just have the single find and include all the likely known components (since the user has them all anyway)
They won't get linked in if they are not used.
taxilian 12:08 hmm. and if they have a custom boost install for some reason?
this would be a lot easier if I'd had time to rewrite the cmake so that it was all project centric instead of multi-project :-/
if we don't specify components will it default to none or all?
perhaps we can just leave it blank and it will get all of them
Gordon_LN_ 12:08 FYI - Up until a month ago, I just build FB with DB_RELEASE=TRUE and did a find_package(FB) in my cmake project...
taxilian 12:08 DB_RELEASE?
Gordon_LN_ 12:08 *FB_RELEASE
taxilian 12:08 ahh
how did you deal with the generated projects?
Gordon_LN_ 12:08 They don't change _that_ much - IOW I generated my project initially and ran with that
taxilian 12:08 they don't change that much very often, anyway =] however, FB_RELEASE doesn't by default include those projects
Gordon_LN_ 12:08 I only switched back when I started the MAC work as the OSX support had moved on a _lot_
taxilian 12:08 yeah; that can work if you're not changing computers
eventually it'd be nice to find a way to make the whole thing so it can be broken away from cmake, i.e. just rerun something when you change your pluginconfig
Gordon_LN_ 12:08 But my current solution is ugly too as I have my libs that need to be pulled into the generated prj...
taxilian 12:08 but while we may be to the point that that could be possible, I haven't had the time to do it
? why would you need to pull libs inot the generated project? I'm talking about the PluginAuto project, not your plugin proj
Gordon_LN_ 12:08 Ahh sorry...
taxilian 12:08 no, the fbgen generated project isn't a big deal
Gordon_LN_ 12:08 Couldn't PluginAuto be generated via CMAKE using "in" files?
taxilian 12:08 it's the PluginAuto project where the real weirdness happens
it *is* generated that way, or at least the headers it uses are
look at gen_templates; the whole directory is files that are configured per-plugin
and the PluginAuto project uses those generated files, wouldn't work without them
Gordon_LN_ 12:08 If there was a proper FindPackage(FB) file it could do it in there?
taxilian 12:08 the reason that the cmake is structured the way it is dates from a time when we only supported one mimetype per plugin project. It took a *lot* of cmake and template magic to make multiple mimetypes work properly. Used to be not uncommon to have multiple projects and build them together
it's possible; I don't know enough about FindPackage files
read: I don't know anything about them
my only experience with cmake is writing FireBreath, so there could certainly be some significant improvements made
Gordon_LN_ 12:08 It is thankless work (cmake work that is)
taxilian 12:08 and like I said; I'd love to refactor / rewrite all the cmake, but haven't had time
emicastro 12:08 sorry, I cann't find CUR_GUID definition? it a ATL constant or something like that?
taxilian 12:08 emicastro: look at the @@foreach line; CUR_GUID is an iterator variable
it comes from whatever variable came before it on the foreach line
Gordon_LN_ it would need to generate the files and then add a new project including those files; can you do that with FindPackage? I thought FindPackage could only pull in libraries and headers?
emicastro 12:08 and that @@foreach is ATL sintax?
or cmake?
taxilian 12:08 emicastro: it's more magical syntax a la taxilian's configure_template.cmake file
emicastro 12:08 jajaja!
ok :)
taxilian 12:08 question not the black magical syntax of my configure_template.cmake file, for it is totally undocumented, completely bizarre, and likely could give you a headache if you try to follow it
emicastro 12:08 if I do a set (A "a") on .cmake and in the same file a lines after I do set(A "b" "c") .... this last setting are overriding the previous one?
taxilian 12:08 emicastro: correct
if you want to add to it you'd need to do:
list(APPEND A b c)
Gordon_LN_ 12:08 FindPackage could return a list of source files which you could just add to your project,
Or a folder at least
emicastro 12:08 cause I'm looking that on my PluginConfig.cmake
taxilian 12:08 Gordon_LN_ I'd prefer not to add things to your project; that creates the illusion that it's okay to edit those files =]
and causes more support issues for me
Gordon_LN_ 12:08 But I would let it find the ".in" files and then generate it into the current project?
emicastro 12:08 the ACTIVEX_PROGID is been setting two times
taxilian 12:08 emicastro: huh
emicastro 12:08 here # these are the pieces that are relevant to using it from Javascript
Gordon_LN_ 12:08 (and add it to a folder called DO_NOT_TOUCH)
emicastro 12:08 and then under #strings
¬¬ I really do not whom create this... I want to do the plugin again :)
but as always, there is no time! :)
taxilian 12:08 Gordon_LN_ I dont' want to copy the PluginAuto files into their project, though; there are a lot of files there, and all they need is to be used, not copied or configured
I am really concerned about confusing people with that approach
emicastro 12:08 REGKEY_ROOT this is making reference to HKEY_CLASSES_ROOT?
taxilian 12:08 which line?
it's either HKLM or HKCU
emicastro 12:08 kk
taxilian 12:08 (depending on the settings of your plugin)
emicastro 12:08 which settings?
taxilian 12:08 grep for it
good experience =]
(sorry, I really am on a time crunch)
emicastro 12:08 haha ok no problem :]
emicastro 13:08 taxilian: in which keys the NPAPI browser are watching to know if there is a plugin installed? There are different locations for 32 and 64 ?
taxilian 13:08 32 bit goes into HK??\Software\MozillaPlugins
64 bit goes into HK??\Software\Wow6432Node\MozillaPlugins
emicastro 13:08 ok, In the gen/FBControl.rgs generated by the prepXXXX.cmd I could see that difference?
I mean the FBControl.rgs created by 32bit and the one created by the 64bits version
taxilian 13:08 hmm. no, not really
you could put it in a cmake variable
but there are no if statements in that file
so the best you could do would probably be to have a variable that is sometimes "Wow6432Node {" and another "}" but only when 64 bit
emicastro 13:08 mmm I see
I think that I was a little crazy :)
taxilian 13:08 hehe
emicastro 13:08 Go to the start of all the times!!! hahaha
taxilian 13:08 you begin to appreciate the work that has actually gone into this project… and that's just one small piece
emicastro 13:08 the only diferrence to create a 32bit and a 64bits dll is create the solution with prep2008.cmd and prep2008x86.cmd
taxilian 13:08 yes; but you can detect which generator was used to create the project
so you can check to see if "x64" is in the generator name
and set the variable based on that
emicastro 13:08 and then you have to compile this solutions and this is it
taxilian 13:08 yeah; but the .rgs file will be configured for each configuration
I assume you're using a different build dir for 32 vs 64 bit?
emicastro 13:08 yes
but if you don't change anything... I'm trying to figure out the happy path...
clean firebreath installation
you create two builds directorys
one with prep.cmd and other with prepx64
the same .rgs are generated for every solution
I'm right at this point?
taxilian 13:08 correct
so to fix your problem, you need the .rgs file to be slightly different for x64 than for normal
emicastro 13:08 ok ok, but before that
taxilian 13:08 I guess the other possible solution would be to use a different id for the x64 build
it would result in the 64 bit version being registered in the 32 bit area, but as long as it doesn't override it that probably isn't a technical problem
and you could do that just in PluginConfig.cmake
emicastro 13:08 I've done this with my project... Having the 32 and 64 bits dll with the same .rgs files... The "crazy" part is that I register the 32bits dll and it created an entry in HKEY_CURRENT_USER\Software\MozillaPlugins.... Everything is ok with that... but... when I register the 64bits dll, it override the HKEY_CURRENT_USER\Software\MozillaPlugins also instead of create a new one on HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MozillaPlugins
taxilian 13:08 that's what I just said
if you change the id for 64 bit then it won't override it
it isn't the "ideal" fix that would fix it for all firebreath plugins, but it would make your plugin work
emicastro 13:08 allright but changing the id, I could have two plugins registered at the same time, that handled the same mime type
taxilian 13:08 yes
emicastro 13:08 is that a problem?
taxilian 13:08 it will use the first one it finds that will load
the 32 bit one won't load in 64 bit, so it doesn't matter
in fact, it aparently scans the registry for 32 bit in addition to 64 bit anyway, so you'd have that either way
emicastro 13:08 The id that I have to change is FBControl_GUID ?
taxilian 13:08 no
emicastro 13:08 which one
taxilian 13:08 MOZILLA_PLUGINID'
emicastro 13:08 the only one? the others could be the same?
taxilian 13:08 yeah
that's the only one used in the key name
emicastro 13:08 great, I'll try it, and I hope this finish with this nightmare hahaha
Elliott_D 14:08 Hello all, Does firebreath use any platform specific #defines? I could define my own in the projectDef.cmakebut if there's already a #define WIN32 or something I'd rather use it.
taxilian 14:08 FB_WIN
Elliott_D 14:08 Okay, thanks! Where are these defined? I grep'ed but couldn't find them.
taxilian 14:08 passed into the compiler
Elliott_D 14:08 Fantastic! Thanks again.
taxilian 14:08 good luck
matutetandil 14:08 taxilian: What version of boost is using FB 1.6??
taxilian 14:08 FB 1.6, if you get everything from git, has 1.45
matutetandil 14:08 ok... If I want to use 1.50, what I have to do?
taxilian 14:08 update to master
it's stable
matutetandil 14:08 ok
FireBreathBot 14:08 Commit 122173e on firebreath-1.7 by Richard Bateman: "Update packaged boost to 1.50.0"
taxilian 14:08 or 1.7; I just pushed the changes to there too
FireBreathBot 14:08 Commit 7d5864b on firebreath-1.7 by Richard Bateman: "Fix for pch memory buffer size"
Commit 95f7bf0 on firebreath-1.7 by Richard Bateman: "Untested tweak of windows PCH; enabled PCH on Mac"
Commit 7025764 on firebreath-1.7 by Richard Bateman: "Updated/improved PCH usage and performance on windows"
Commit 0cb277a on firebreath-1.7 by Richard Bateman: "Mac PCH headers now working correctly"
Commit 2f0f8ba on firebreath-1.7 by Richard Bateman: "Add boost::process to the included boost"
Commit aa62148 on firebreath-1.7 by Richard Bateman: "Updated packaged boost"
taxilian 14:08 literally just
matutetandil 14:08 excelent!!!!
I'm going to test my IPC issue now, using boost 1.50... I'll tell you the news
taxilian 14:08 any responses on stackoverflow?
matutetandil 14:08 nop
taxilian 14:08 it's just not really a well understood area, unfortunately
I edited it to help clarify what you need, but that's all I can do to help, I'm afraid
let me know if it works with 1.5
matutetandil 14:08 it doen't work in 1.5... :S:S:S
taxilian 14:08 probably something more fundamental
matutetandil 14:08 this is very wired!
taxilian 14:08 if I were you I'd try stepping into the internals of what is happening when it tries to create it
somewhere there will be a system API call
matutetandil 14:08 perhaps
taxilian 14:08 maybe you can find out what is failing and it'll give you an idea of how to fix it
matutetandil 14:08 yaps... I spend all the day searching for that... I don't know really where to search... google forums says that may work and there is no sandbox arround...
taxilian 14:08 don't search
step in
try to figure it out yourself
matutetandil 14:08 yaps... I'm going to do that! thaks fot the help!
emicastro 14:08 taxilian: where key the IE check for plugins detection?
I changed the mozilla_pluginid and now I have 2 entrys on MozillaPlugin one for 32bit and one for 64bits
but the IE10 (64bits) does not see the plugins :S
taxilian 14:08 emicastro: IE will just work
that I can't explain
emicastro 14:08 wow... F5 and is working now
really really strange
cause I have the browser closed when I register the plugin
matutetandil 15:08 I try using shared memory instead of messages queues... same error... grrrrrrrrrr!!!!!!!!!!! I'm start thinking that they are in diferent memory spaces :S:S:S
johannes 16:08 is it my configuration or is visual studio 2010 really bad in browsing (FireBreath) code? I simply try to jump from declaration to declaration and each search takes "ages" ..
taxilian 16:08 johannes: update to the newest 1.7
it'll help
johannes 16:08 I'm on master :-)
taxilian 16:08 on the latest?
johannes 16:08 yesterday's
taxilian 16:08 probably as good as you can get
johannes 16:08 according to task manager the search is fully cpu bound, not io, no memory size issue ... maybe i can give an extra core to the vm ...
taxilian 16:08 dunno; my VMs don't have too much trouble with it
and it's a lot better with the newest
johannes 16:08 well, maybe i setup something badly ... usually i only use it to test stuff and then complain to a colleague if it fails :-p
ut i#ve found the place I was looking for, i'm happy :-)
icet402 18:08 NPAPI provides a mechanism for downloading from a url: NPN_GetURL. Is it strongly recommended to use this over the much easier native API's such as URLDownloadToFile (windows) or those provided by Cocao (mac)?
taxilian 18:08 yes; the reason being that if you use NPN_GetURL then it uses the browser's proxy settings
icet402 18:08 Are there particular security issues with one over the other?
taxilian 18:08 not that I can think of offhand
icet402 18:08 Thanks for your help... and for answering so quickly!
Binbo 20:08 in the plugin,given I have declare a boost thread as private member and it was initiated in a method. Then open the plugin in two tabs. Does this thread shared the same memory ?
taxilian 20:08 yes, all tabs share the same memory
all instances in the same browser share the same memory, tabs, windows, whatever
and threads of course share the same machine
Binbo 20:08 taxillian : actually I used this thread to make a listening socket. So If I closed one of the tabs, the remaining tab listening socket get interrupted. Is there any workaround in term of my code structure in the plugin?
taxilian 20:08 do it in global space
and close things down in StaticDeinitialize
gotta run
I'll be on tomorrow, business hours GMT-0600