IRC Log Viewer » #firebreath » 2012-09-16

IRC Nick Time (GMT-7) Message
jshanab 10:09 Good morning everyone.
I am trying to debug in mac and have Xcode stopping on my breakpoints now. But when I step thru the code, in one area, it drops to machine language. This is a static library who's source code is in the plugin project. How do I get it's symbols loaded or point it to the source code so I can continue stepping in C++?
johannes 13:09 compile the library with debugging symbols (i.e. -g compiler option)
taxilian 13:09 jshanab: yeah, that's pretty much it on mac; the lib has symbols or doesn't
johannes 13:09 and well, learning machine language good enough for reading it is also a good skill to have :-)
jshanab 15:09 To bad xcode does not let you inspect values in that mode. I am surprized that 1 lib in the project is without symbols and the rest have it, I will check the CMake, I hijacked the existing one and it probably has it's own CFLAGS
I actually like assembly (not machine language) as long as it is not x86. x86 assembly sucks
imbroglio 15:09 when your derivative of PluginCore get's control, how do you know what kind of plugin the framework has created?
taxilian 15:09 imbroglio: what do you mean, exactly?
what kind? as in npapi or activex?
what problem are you actually trying to solve?
imbroglio 15:09 right npapi or activex
taxilian 15:09 while I find the name of the property that tells you, why does it matter?
(PluginCore::Browser should tell you what you need to know; I forget the exact values, but that's easy enough to grep for or look at)
imbroglio 15:09 are you saying the plugin core extension doesn't need to do anything different in those two cases?
taxilian 15:09 yes, that's exactly what I'm saying
at least in 99% of the cases
imbroglio 15:09 oh, OK
I presumed it would be in browser host or something, but the larger feedback you just gave was what I was looking for.
taxilian 16:09 you could also figure out what type of browserhost it is, but it would be very very rare to need to care
imbroglio 16:09 imbroglio was the captcha on the live chat page
taxilian 16:09 the whole point of FireBreath is to be an abstraction so that you don't care
lol. that is pretty funny
imbroglio 16:09 yeah, the code I'm migrating to your fw is rife with AX vs NP
why doesn't the fw set the entry points then?
taxilian 16:09 sorry, what? which entrypoints are you referring to?
imbroglio 16:09 maybe it does, actually, talking about the NPAPI GetEntryPoint call
taxilian 16:09 it does all of that
pretty much anything that you're currently doing where you call anything starting with NP you aren't going to do anymore
at least not in that way
imbroglio 16:09 yes, I see that now
taxilian 16:09 before you go any further I'd recommend that you create a skeleton plugin wtih fbgen
then you can look at what is generated and you'll start to see how you're doing things
then you can look at what is behind if you want to
imbroglio 16:09 got it, thx
it's not as simple as you portray though
for example you don't implement a NP print function
taxilian 16:09 that is true; I have never had a need for it. Like all open source frameworks, if you need that functionality you might want to consider adding it and submitting a pull request =]
imbroglio 16:09 I have no choice to add it and the other missing functionality. My client can make decisions about contributing to the project, dunno what their position is on that.
taxilian 16:09 well, it's licensed under new BSD, so it's their decision of course
imbroglio 16:09 I thought it was dual
taxilian 16:09 but TBH it would be foolish not to; it gives nobody a competitive advantage (since it's such a small piece) and it's always good to have your code vetted by more people, plus they get any improvements others make on the framework for free
it is, whcih means you get to choose which to use
you can use LGPL if you want, but then you'd have to open source your whole plugin
which seem like probably not what you want
imbroglio 16:09 this is strictly work for hire, any licensing issues on what I turn over to them is between them and you or other third parties
taxilian 16:09 right
I'm just giving you the information to pass to them =]
particularly since I'm much more interested in helping you find the best way to deal with printing if the framework improvements will make it back to firebreath
imbroglio 16:09 i'm also not functioning as a mgt consultant for them, though the typical client I deal with does implicitly require such
well I just have to adapt the prior NP print function to your fw
taxilian 16:09 well, good luck
hope it goes well for you
imbroglio 16:09 thx
it will. this is just tedious stuff, not really interesting but does pay something, pretty sure I'm gonna retire after I close out this and a couple of other jobs, after that I will only work on stuff that interest me
taxilian 16:09 hehe. plugins can be a pain, no question
imbroglio 16:09 there's a guy on #xchat whose nick is LifeIsPain
there are computing environments that are fun but browser plugins, most commercial work doesn't fit that category for me
anyway thanks, just wanted to see what this chat client looked like
taxilian 16:09 hehe. it's just an IRC web client, but it works well enough
good luck
JuanDaugherty 17:09 anybody had to modify the plugin auto window proc?
rkjnsn 18:09 Hey, all. I'm running into a problem building with NMake on Windows.
While my project builds fine using Visual Studio and using Makefiles on Linux, trying to build with NMake Makefiles on Windows fails with the error: C1083: Cannot open precompiled header file: '[build dir]/ScriptingCore/./precompiled_headers.pch': No such file or directory
(Of course, the error has the actual full path, not '[build dir]')
jshanab 18:09 Are you running NMake at the correct level such that it includes and builds the Firebreath parts before your parts? I have done something similar on MAc that got me in trouble
taxilian 18:09 JuanDaugherty what do you need to modify the winproc for?
rkjsnsn: never tried using nmake, so I'm not sure; I would think it would work the same as visual studio, but no idea
JuanDaugherty 18:09 lol, you always ask that, the answer is always the same
taxilian 18:09 I'm trying to understand what problem you are trying to solve
sometimes there is a better solution
in this case there are 2 different ways you could do it, so I'm trying to understand what you're trying to do so I can suggest the right solution
JuanDaugherty 18:09 as a point of order, if I say "anybody" that means users of your pkg and not you
taxilian 18:09 I know
I honestly was not trying to imply that you shouldn't be doing that
just trying to understand the problem to offer help
JuanDaugherty 18:09 and you in a minimum number of words name the two ways
taxilian 18:09 because I have certainly modified the winproc multiple times =]
JuanDaugherty 18:09 *can you?
taxilian 18:09 cetainly
that still leaves the question of whether or not that's the best solution
I guess if you're determined that is what you want to do then you can make the call on your own and I'll tell you what to do; I've just become accustomed to making sure I understand the problem because otherwise I *very* often explain how to do something only to find out later that I could have saved them a lot of work with a simpler solution
JuanDaugherty 18:09 what is it that you conceive of a plugin doing in your fw? Maybe you should make this clear somewhere. An app that was displaying a MIME type for example needs to have full access to the core GUI.
taxilian 18:09 I conceive of a plugin doing *anything* that a plugin can do
JuanDaugherty 18:09 but as I've said before it's all good, the sources are here and clear
taxilian 18:09 and if that is what you want, then your best bet is probably not to actually change the winproc
what you want to do is create your own window as a child window of the plugin's main window
JuanDaugherty 18:09 right that was my intent, glad to hear you confirm it
taxilian 18:09 the reason is that if you subclass the window yourself you'll kill some of FireBreath's internal workings and if you use firebreath's abstraction for giving you access to those (there are two ways) then it won't give you enough access
that's why I wanted to know what you were wanting to do; most people wanting to "change the winproc" just need access to a few extra messages or something
just trying to make sure I understand the question =]
JuanDaugherty 18:09 to get the print proc in the function ptr table though I'm going to have modify FB sources anyway so that Rubicon is crossed
taxilian 18:09 ? the print proc is already in the ptr table
or it should be
isn't it?
you mean NPP_Print, no?
JuanDaugherty 18:09 the one was small, the second not so small, dunno about after that but part of the value of this deliver is you and your fw so of
course will try to colour within your lines as much as possible
taxilian 18:09 again, you probably don't need to go outside of them. there are a lot more customization points than really anyone has ever used
but if you can prove me wrong I'll try to add more =]
JuanDaugherty 18:09 you mean in the browsers default NP vector table?
taxilian 18:09 my philosophy is that it should always be possible to customize; no abstraction can cover everything
that table should already have all possible functions
and it should be possible to add your own NPP_Print without modifying firebreath code
JuanDaugherty 18:09 because it's not in the version of npapihost.cpp I have
taxilian 18:09 unless you want to add it to the abstraction, in which case modifying the code is probably what you want to do
you mean browserhost?
browserhost is the abstraction
not the actual implementation
the actual implementation is here:
JuanDaugherty 18:09 no but I have to say, I'm looking at the Eclipse IDE, not VS in saying that, presume it's the same on DOS
taxilian 18:09 so if you want to override it instead of changing fb sources you just have to override the factory method that creates the npapiplugin method
to return a different NpapiPlugin class than the default (and to provide your own NPP_Print method) you can override this:
in your factory class
in the factory you can override pretty much any of the classes
anyway, I gotta run, but if you do want to keep it compatible wtih core firebreath sources that might help
good luck
rkjnsn 20:09 taxilian: I'm running 'nmake' at the top level, the same level at which I successfully run 'make' on Linux, so I don't think that's the problem. Linux doesn't use PCH, though correct? Could it be that the PCH logic in the build system doesn't take the MSVC but not Visual Studio case into account?
JuanDaugherty 20:09 linux definitely doesn't use pch
the alternation in the cmake file is msvc versus apple, as taxilian_pointed out to me, don't think he actually develops much on Linux but he should say
(assuming you mean precompiled headers)
rkjnsn 20:09 Yes.
rkjnsn 20:09 Hmm... my guess is that it is a dependency problem.
It looks like the macro neither tells CMake that the .pch file gets generated, nor that other objects in the target depend on it.
Thus, the dependency isn't written to the makefile.
I'll probably just change "IF(MSVC)" to "IF(MSVC_IDE)" for now.
rkjnsn 21:09 Okay, I ran into another problem.
When building ScriptingCore\JSAPIAuto.cpp, I get the error 'CreateEventW' is not a member of FB
It seems that it is trying to call CreateEvent from JSEvent.h, but the Windows headers have decided to #define CreateEvent CreateEventW
rkjnsn 22:09 taxilian: Would you be willing to make it possible to build without precompiled headers on Windows? (i.e., with the contents of the ADD_PRECOMPILED_HEADER macro commented out)
taxilian 22:09 add the code, send me a pull request
or I could probably add it in tomorrow
but it'll be faster if you just throw it in
all you need to do is add an if statement around the contents that some variable isn't defined
then pass that var into the prep script
rkjnsn 22:09 That part's simple enough. The problem is that it currently causes build errors because includes are evaluated differently.
taxilian 22:09 ahh
add a jira issue
I will get to it, but it may be awhile
rkjnsn 22:09 Okay, will do.
rkjnsn 22:09
FireBreathBot 22:09 FIREBREATH-199: Summary: Firebreath won't build on Windows with precompiled headers disabled
FIREBREATH-199: Assigned To: richard
FIREBREATH-199: Priority: Minor, Status: Open,
taxilian 22:09 thx
now it's on my list and I have no excuse to forget =]
rkjnsn 22:09 ^^^ That's fancy. :)