IRC Log Viewer » #firebreath » 2011-01-20

IRC Nick Time (GMT-7) Message
Ed_____ 06:01 Noob to firebreath/CMake, any pointers on building a library (dll/so) from source as a dependancy and including it?
iaincollins 06:01 hey
well quick and dirty way is to include a reference to a .lib file in your class, e.g. using #pragma
#pragma comment(lib, "winhttp.lib") // For example
you could also extend the cmake files to look for and include your library
Ed_____ 06:01 I have source code for a library that I want to dynamically link to my plugin, and so I need to presumably add some instructions to a CMakeLists.txt to build and link..
iaincollins 06:01 I think there are some notes on that in the wiki
http://www.firebreath.org/display/documentation/Using+Libraries
Ed_____ 06:01 Yeh, I had looked at that..
iaincollins 06:01 I think I saw some more recently, hmmm *looks*
Ed_____ 06:01 The response I get from prep2008 is:
Cannot specify link libraries for target "Webphone" which is not built by this project
I added the target_link_libraries () command, but I guess I need to also tell it about the source files..
iaincollins 07:01 oh hmm my only dependancies right now are common platform libraries
Ed_____ 07:01 ah
iaincollins 07:01 I see it says on that page:
"NOTE: target_link_libraries must come after the add_library command (or add_plugin when a firebreath helper function is used). This means at the end of the plugin project CMakeLists.txt file if it is a normal fbgen-generated project for global or at the end of projectDef.cmake for platform specific."
I don't know if that helps, but just in case you missed it :)
Ed_____ 07:01 Ok, prep2008 error has gone.
I'll see what the VS solution looks like now..
Ok, so if I add the add_library() call, I should get a new project that creates the library..
iaincollins 07:01 I don't *think* it does that, just includes it in the build process, so the linker can find it
are you looking to build the project too, as part of the FB build process?
Ed_____ 07:01 It seemed to be the best way to put it all together..
iaincollins 07:01 If so, knowing how to do that is beyond me :) sounds like it would require modifying the FB templates, but I am not the best person to ask
it might be easier just to have the .dll file(s) and .lib file seperately and just included
I can understand why you'd want that, but might take a bit more work and may not be worth the hassle
Ed_____ 07:01 Ok, that might be possile - it would make for a two-stage build, but not terrible.
iaincollins 07:01 am being being lazy, but if it requires modifying the templates might not been keen on doing that every release of FB :)
Ed_____ 07:01 Trouble is I am pulling in out stack which resides in several dlls..
iaincollins 07:01 I have a similar consideration myself, as I'm leaning towards reusing code in the plug-in in other projects (to have one cross platform C++ codebase, rather than have the same functionality in different applications, in multiple languages, as we do currently)
Ed_____ 07:01 I think if I put in an add_library, that should do the stuff needed to build the shared library and target_link_libraries() should link it.
Yeh, we have a cross-platform stack. using seperate makes on each platform.
Added add_library()
iaincollins 07:01 I currently have one project in SVN, with the plugin and exectuable in another, but with common files, but all build into a single DLL or executable at compile time.
^ gah, I've lost the ability to type coherent sentances in the last month. I think it's my New Years diet.
Ed_____ 07:01 okay, probably getting closer now..
getting: "CMake Error: CMake can not determine linker language for target:<library>"
I still follow the seafood diet..
iaincollins 07:01 Oh this might help:
http://groups.google.com/group/firebreath-dev/browse_thread/thread/43ab0ab205fd0e0f/03672077e1159b30
Ed_____ 07:01 I shall have a look. looks promising. ta
iaincollins 07:01 sounds like you're past that, and the formating there is a bit hard to read, but might be helpful (might be other mentions of it on the Mailing List too, probably worth a look, probably where I recall seing it come up)
Ed_____ 07:01 option 2 is what I am looking at.
neilg_ 07:01 I'm doing a similar thing as it happens (which is working for me!)
[dudu] 07:01 hi
neilg_ 07:01 Hi
Ed_____ 07:01 Hi Neil. So, I added a file declaration to list the files, then add_library(lib SHARED ${LIB_FILES})
Then added a target_link_libraries(..)
iaincollins 07:01 brb (and thanks neilg_, look forward to reading :-)
neilg_ 07:01 Sure, that makes sense
Ed_____ 07:01 But I am getting the cmake error:
"CMake Error: CMake can not determine linker language for target:<library>"
neilg_ 07:01 Where did you put that code?
Ed_____ 07:01 So, I guess there is just a little bit more I need for prep2008 to work..
neilg_ 07:01 You should put it in Win\projectDef.cmake in your project directory
For instance, I have a library called common_cpp and in my projectDef.cmake I have the following lines:
set (COMMON_CPP_DIR ${FireBreath_SOURCE_DIR}/external/common_cpp/lib)
target_link_libraries(${PLUGIN_NAME} debug "${COMMON_CPP_DIR}/debug/mlcommon.lib")
target_link_libraries(${PLUGIN_NAME} optimized "${COMMON_CPP_DIR}/release/mlcommon.lib")
And that parses correctly and links against the correct release and debug versions of the library
Ed_____ 07:01 Does it build the source too?
neilg_ 07:01 No, the library would have to be already built. Otherwise you could do it but you'd have to write another CMake script to do that
Ed_____ 07:01 ok, that is what I am looking for..
iaincollins 07:01 sounds like the ExternalProject functions might help with that
Ed_____ 07:01 Ok, it now says my file list is empty for the library, so I may have smudged a path somewhere
Yeh, I think I am going to just try building it externally for now.
iaincollins 07:01 *puts off learning cmake, again*
Ed_____ 07:01 he he
i'm tring'..
neilg_ 07:01 Oh, I guess I didn't read far enough up! Well, that starts to become complicated then! You could do it but you'd need to reference it somehow (and I assume this is outside your FB project tree?)
Ed_____ 07:01 it is outside the project tree..
[dudu] 07:01 Hi, (again) so i'd like to ask for some pointers: i'm building a plugin under linux that uses v4l device to grap pictures, and now i want to display them. The default pluginwindowx11 class uses gtk's drawingsurface, but how should i get hold of the gtkwidget pointers? (they are protected)
If i make a subclass out of PluginWindowX11 how do i make the system use that instead of the PluginWindowX11?
iaincollins 07:01 [dudu] Hmm if no one can help right now, the mailing list is a really good place for questions like that
You can find a link to the signup up here http://www.firebreath.org/display/documentation/Getting+Help
some related questions have been discussed recently I think
[dudu] 07:01 since its on github, i have the power of [fork] button, but i guess that's not the path i should take :-P
thank you, i'll take a look
iaincollins 07:01 gl :)
neilg_ 07:01 You (most likely) should subclass PluginWindow, not PluginWindowX11
[dudu] 07:01 I've found some suggestions here: http://colonelpanic.net/2010/11/firebreath-tips-drawing-on-windows/ , but i'm not sure, what to do exacly, fortunately i dont need platform independence.
Ed_____ 08:01 Neil, Ian - as an update.. Looks like I am just missing the source files (it found some headers), so if I correct the paths, I can see it will create the appropriate project when prep2008 succeeds, and I should be able to build in one shot..
iaincollins 08:01 oh! let me know how you get on
I've remembered I was actually linking curl into 1.3 at one point (though there were problems, but related to how it was building)
I can't remember how I was doing that though 8) but it was just a pre-built library anyway
*but not related (yep, definitely can't concentrate without food)
Ed_____ 08:01 Yeh, I feel a need for some choc. Maybe just coffee will have to do for now.. 8-/
taxilian 08:01 Ed____: yeah, the error you were getting just means "CMake didn't find any cpp files or .c files, so it doesn't know what the project is
iaincollins: You can add other cmake projects from within your plugin project easily; no need to modify FireBreath projects
dudu: hang on, looking at the PluginWindowX11 class real quick so I can answer your question better
neilg_: you can have multiple add_library commands in a single cmake file; it's just usually cleaner to include another one
neilg_ 08:01 Yup, I have multiple add_library commands in my projectDef.cmake file
I was just trying to help Ed____ but his complications mostly came from wanting to compile the external library first
taxilian 08:01 cmake determines build order based on dependencies
[dudu] 08:01 Oh, thans... in the mean time, i've found the Factory that the post was talking about (not needed to move, it was next to the other generated files) so i'm trying to override the createPluginWindowX11 that comes with FactoryBase
taxilian 08:01 dudu: yeah, but I would avoid that unless you need to
that's more likely to change and break between releases
look at https://github.com/firebreath/FireBreath/blob/firebreath-1.4/src/PluginAuto/X11/PluginWindowX11.h
you have getWindow
and getBrowserWindow
those should give you what you need
iaincollins 08:01 taxilian: I was assuming they wern't other cmake projects already (although actually, that was a bad thing to just assume!)
taxilian 08:01 iaincollins: despite what everyone seems to assume, creating a new cmake project when you have source is usually very easy =]
I need to write some docs, but I haven't had time yet
here is an example simple cmake library project: https://github.com/firebreath/firebreath-boost/blob/master/libs/regex/CMakeLists.txt
it's static, not shared(dynamic) but that's a simple change
[dudu] 08:01 yup, i can get the window instance, but the public functions doesn't realy help me to draw on the protected m_canvas object, only with sizing and clipping
iaincollins 08:01 thanks
taxilian 08:01 dudu: the protected canvas isn't what you should be drawing on
that's the browser's canvas, not yours
the canvas you want to draw on is what you get from getWindow
[dudu] 08:01 Oh
taxilian 08:01 dudu: at least, that's what my understanding is. I didn't write that part; I don't know much about linux drawing, I'm afraid
hmm. it doesn't really look like that, though; hang on, let me read some more. something here has changed since I last read it
ahh, no, this is right. getWindow does return GDK_WINDOW_XID(gtk_widget_get_window(m_canvas));
so it gets you the window for the canvas you should draw on
which is what you want. (at least, the people who did that, who use it, tell me that's what you want)
I don't see any of them here right now
hara: welcome, btw; let us know if you have any questions
[dudu] 08:01 taxilian: thank you, i'll try to add some widgets to it and will see (-:
taxilian 08:01 keep me posted; also, if you could find it in your heart to contribute any simple examples that'd help future linux devs avoid having the same questions you have
Ed____: what I would do in your place is make another CMakeLists.txt in the directory with your library, then add_subdirectory that directory
then you should be able to do target_link_libraries (good call iaincollins on spotting that the order matters for where that goes =]) to link to that project
and have everything built in cmake fairly easily
I need to take a shower and get ready for school; I'll be back online in about an hour and a half
any quick questions before I go? (you have 2 minutes to respond :-P)
iaincollins 08:01 maybe later, but the new expanded examples will answer them I think 8)
taxilian 08:01 =
=]
iaincollins 08:01 (loving JSObjectPtr!)
taxilian 08:01 thanks for being here to answer questions in the early hours of my morning when I sleep =]
hehe. it's nice how easy it is to do things interacting with the page, isn't it?
iaincollins 08:01 no worries, just playing receptionist (keeping people occupied, second pair of eyes until someone more useful shows up)
it really is, major re-write for me to move to 1.4 (as it's very much based around passing objects back and forth)
taxilian 08:01 hehe. well, you could always leave it the old way… =] that should still work
iaincollins 08:01 but entirely worth it as it gives me a chance to refactor the design and actually it's encouring a better design
taxilian 08:01 the new way is just cleaner =]
Ed_____ 08:01 Hi Taxillian, just spotted you response.
taxilian 08:01 if you encounter things that ought to go there, feel free to update the "Best Practices" stuff
Ed____: yeah, sorry I couldn't help sooner, I just woke up
iaincollins 08:01 It's not very happy with the old way with my code, actually triggers compile time errors in the boost libraries (!) thats probably a sign though ;-)
Ed_____ 08:01 Thanks for that, I am starting to build an understanding of cmake, so things are gradually becoming a bit less opaque.. 8D
taxilian 08:01 iaincollins: I'd have to see the errors; they probably either indicate a major-ish problem or just need a slight tweak
iaincollins 08:01 yeah will do, am keeping an eye out for things to note in the wiki
taxilian 08:01 Ed____: yeah, I need to write some cmake docs for the wiki, but I just haven't had time. I'm impressed with how you stuck with doing it the way you're doing it (which is really the correct way) despite all the skeptics :-P
I will be online most of today, but on and off. I need to go get ready for school now
iaincollins 08:01 taxilian: I need to change the design anyway (to be able to support some new features) so happier to redesign it :)... have good day!
Ed_____ 08:01 Taxillian: I just know that if I create a long multi-step build I'll miss a step and drive myself insane at some point until I realise..
taxilian 08:01 Ed____: I hear you there
Ed_____ 08:01 Taxillian: just not enough days in the hour - as you say!
taxilian 08:01 lol. you got that right. anyway, be back later (probably ~1.5 hours)
Ed_____ 08:01 ttfn
[dudu] 09:01 Ah, i see how could not see the GDK_WINDOW_XID(...) stuff, i was using 1.3 branch, the 1.4 keep dying on firebreath/src/3rdParty/boost/boost/thread/pthread/pthread_mutex_scoped_lock.hpp:26: boost::pthread::pthread_mutex_scoped_lock::pthread_mutex_scoped_lock(pthread_mutex_t*): Assertion `!pthread_mutex_lock(m)' failed.
taxilian 09:01 Hmm
Driving now
[dudu] 09:01 soz
taxilian 09:01 Dudu: I have seen that error before but I cant reproduce it. Any chance you would be willing to try to track it down?
scJohn 09:01 taxilian, i was playing around with the onload event this morning.. I learned the hard way that you must define the javascript handler before the plugin (I put my js at the bottom of the page)
and Chrome will crash if you don't have the handler before the plugin, whereas ie will just not do anything.
probably just a documentation update, what page do you recommend and I will update.
taxilian 09:01 Hmm. Shouldnt crash
Not sure
Where does it crash?
scJohn 09:01 i'll have to bring the debugger back up. i will do that in a couple of minutes
appeared to be a null pointer.
taxilian 09:01 That would be good. Plugins should never crash
If it does even for stupid mistakes in the page it is a bug
Oh, i bet i know why
[dudu] 09:01 i'll give it a try but i'm not big on gdb (or c++ for that matter) so dont promise anything. anyway my day is over (im in CET time zone) maybe tomorrow
taxilian 09:01 Fair enough
Brb
[dudu] 09:01 bb
hara 09:01 hi all
i'm completely new to firebreath
i would like to write a cross browser plugin for opengl rendering
is there an online wiki where i can find how firebreath works?
iaincollins 09:01 hi hara... I think there are a few people doing something similar :)
hara 09:01 :)
iaincollins 09:01 You can find the wiki over at http://www.firebreath.org/
hara 09:01 mmm
iaincollins 09:01 the mailing list is worth joning, and the example projects are very helpful
hara 09:01 i have already visited that site..
iaincollins 09:01 there are some good getting started guides that cover building the examples, and the sources are fairly useful
FB 1.4 is worth checking out in particular
hara 09:01 at the moment i get a zip from google code
cause when i tried to use the sources taken from the repository something didn't work
iaincollins 09:01 oh
hara 09:01 i will try to get the sources again tomorrow..
maybe it was my fault
iaincollins 09:01 it *might* be the examples need updating
err sorry I mean the documentation (but actually no, come to think of it it's still fine)
brb
hara 09:01 i read this article
http://colonelpanic.net/2010/11/firebreath-tips-drawing-on-windows/
i didn't understand, when it talks about "PluginWindowWin" point 2, how to extend the plugin base class to create a specific plugin for windows platform
iaincollins 09:01 yeah that's above my head 8)
hara: questions about that come up on the mailing list a few times though :-) http://groups.google.com/group/firebreath-dev/search?group=firebreath-dev&q=PluginWindow&qt_g=Search+this+group
taxilian 09:01 hara: what didn't work?
hara: have you gone through the getting started guide?
hara 09:01 hi
taxilian 09:01 hi =]
hara 09:01 did u mean about the problem with the sources?
yes..i follow the guide
taxilian 09:01 yeah; what was the problem? "It didn't work" is fairly unhelpful, to be honest...
hara 09:01 i'm sorry but i have to go to get the train...i found the chat too late :S
thanks for your reply
taxilian 09:01 okay. well, they work fine for me, so if you can get me details I can probably help
hara 09:01 i hope to find you tomorrow
taxilian 09:01 the mailing list is a great way if I'm not online (it's morning here)
hara 10:01 thank you!
i will write tomorrow
have a nice day
bye
taxilian 10:01 have fun
hmm. I really really wish I could somehow track down that pthread assertion error
it makes no sense
iaincollins 10:01 hmmm not seeing any issues here on 1.4 (though am now working on other more changes atm)
I think the problem with my code under 1.4 relates to my passing a shared_ptr to an instances of class that extends FB::JSAPIAuto, but am still to investigate that more fully
taxilian 10:01 it only happens on linux
iaincollins 10:01 oh
taxilian 10:01 be very careful where you save a shared_ptr
be wary of circular references
iaincollins 10:01 just FYI, the build errors I am seeing are:
'boost::noncopyable_::noncopyable::noncopyable' : cannot access private member declared in class 'boost::noncopyable_::noncopyable'
'boost::recursive_mutex::recursive_mutex' : cannot access private member declared in class 'boost::recursive_mutex'
taxilian 10:01 hehe. yep, that's your fault =]
iaincollins 10:01 8)
taxilian 10:01 and that is a bug
iaincollins 10:01 I have been looking at some of the stuff I was doing and going "Why did I do that?"
taxilian 10:01 yeah, that's common
there are several classes in FireBreath that are now explicitely noncopyable
so if you get that error, you were trying to copy something that hsouldn't be copied
probably unintentionally
iaincollins 10:01 the Class Reference documentaiton has been super-helpful
taxilian 10:01 good! you're, like, the first person to tell me that
and I've worked hard on it =]
iaincollins 10:01 hah ouch
yeah I could see :) some good notes
taxilian 10:01 I've had a few people complain that there isn't one, though… :-P
iaincollins 10:01 I think it's easy to miss when you don't know /anything/ about it
easy for brains to just gloss over it....
(I think that's a Dr Who plot point)
taxilian 10:01 hehe. yeah; I'm not sure how to improve that, though :-/ I have moved it to an easier to find location on the page
iaincollins 10:01 but pennies are slowly dropping after reading it and the blog articles
I do have a quick question actualy
taxilian 10:01 I like quick questions
sometimes I even answer them!
iaincollins 10:01 if I am returning a single instance of an object, do I want to return type to be FB::JSAPIAuto , or should it be VariantList, even if there is only one?
hah
taxilian 10:01 from a JSAPI method/
?
I would just return it as a ptr to that object. i.e. MyCoolAPIPtr
iaincollins 10:01 Oh okay, cool that's what I've been doing up till now actually
taxilian 10:01 only put it in a variantlist if you need to return an array for some reason
iaincollins 10:01 oh, okay
taxilian 10:01 pre 1.4 you had to return a FB::JSAPIPtr; you can now just use a shared_ptr to the object itself
iaincollins 10:01 aah cool, yes was about to say was using FB::JSAPIPtr
but oh just the object itself, very cool
taxilian 10:01 well, it has to be a shared_ptr to the object
iaincollins 10:01 *nod*
taxilian 10:01 but you'll get a compile error if you try to do just the object, so you'd catch that fast
btw, if you want better control of the lifecycle
you can return a weak_ptr to the object
iaincollins 10:01 okies, I did see there was a typedef for that too
taxilian 10:01 and then whenever your copy goes away (it being the only shared_ptr reference) it'll invalidate the object
iaincollins 10:01 hmm will consider that actually
taxilian 10:01 which personally I think is really cool
so general rule of thumb for storing a shared_ptr; if the object you're storing it in is not the owner (there could be more than one owner) then dont' use a shared_ptr, use a weak_ptr
if A has a shared_ptr to b, which has a shared_ptr to c, which has a shared_ptr to a, they never go away
which is often considered bad(tm)
iaincollins 10:01 oh ouch, well should be avoiding that at least :)
but good to be aware of
scJohn 10:01 taxilian: crash on chrome..
PluginCore.cpp line 137
method must be null
testing now
taxilian 10:01 scJohn: Yeah; I made a change so that undefined or null can be cast to a JSObjectPtr which will then be NULL… so that's gotta be it
scJohn 10:01 k, i just stuck a if(method) above.. i'll let you know if that fixes it.
taxilian 10:01 that should, yes
do you have a fork? you could just push it and I could grab it =]
jtojanen! My favorate COM expert!
jtojanen 10:01 taxilian: something to pick https://github.com/jtojanen/FireBreath/commit/b8ebc8262d000579667d06112ec30cdc52245380
taxilian 10:01 how are you, my friend?
jtojanen 10:01 fine thank you
your chrome fix saved my day :)
scJohn 10:01 ok, that worked. i'll look into the fork thing.
taxilian 10:01 hehe. good; it's always best when this is a two-way street
jtojanen 10:01 you should be apply to cherry pick that single commit
scJohn 10:01 yea, of course that requires me to setup an account, etc..
but i'll get it done.
taxilian 10:01 scJohn: you know you want to :-P
scJohn 10:01 sure thing
taxilian 10:01 jtojanen: yeah, I'm just reading through it
jtojanen: it'll be a few minutes; have you had a chance to glance at my windowless stuff?
jtojanen 10:01 no, sorry I have been working with other stuff here
taxilian 10:01 I understand; I have it mostly working
but I'm missing something
doesn't always draw
jtojanen 10:01 I will try to embed WMP ActiveX inside FB control; that should tell us more about painting
first I will have finish build "container" for ActiveX to host one
taxilian 10:01 there is an example project someone submitted that is supposed to be that
btw, if I were to pull in your change with moving dllmain without any other changes I'm pretty sure we'll get a duplicate symbol error on existing plugins, no?
jtojanen: this may or may not be useful as a starting point for your container: https://github.com/firebreath/FBAXExample
jtojanen 10:01 no it won't make duplicate symbols
taxilian 10:01 hmm. I will try it out, then =] you haven't given me any bad commits yet, so I'm inclined to trust you, though it seems like that conflicts wtih my experience
jtojanen 10:01 If you have DLL implementing something it doesn't need to look for "unresolved" from library
taxilian 10:01 ahh; so you can override a symbol locally
jtojanen 10:01 yep
taxilian 10:01 if it's just an entry point
I guess that makes sense
I'll go with that fix, then; just as soon as I test it =]
btw, I have the shutdown stuff happening now, but setClientSite(NULL) is still not called, at least with ATL 10
it seems to be called when we use vs express
really baffling
FBControl is never destructed either
jtojanen 10:01 so still work needed
taxilian 10:01 right
jtojanen 10:01 i will leave home but later then.
taxilian 10:01 I've gone through everything I could think of; found a few things, but still must be missing something
iaincollins: any progress on getting the irc log parsing stuff somewhere where I can help?
scJohn 11:01 if i did this correct, git://github.com/scjohn/FireBreath.git
iaincollins 11:01 no sorry :( and I'm being dragged out to dinner right now (oppressively, against my will, by a girl, boo *ahem*). I suck.
catch you all later, will try and get it finished
scJohn 11:01 taxilian: I am recommitting with spaces instead of tabs.
taxilian 11:01 scJohn: okay =] I actually have a fixtabs command that automatically fixes all of htat that I have to run periodically :-P
I used to like tabs as well, the problem is that it always messes up source control tools
scJohn 11:01 i hate spaces.. python is painful
taxilian 11:01 hehe. well, with a good editor they work about like tabs
scJohn 11:01 i know
taxilian 11:01 but between using python and having all the source tools treating them differently… I finally just gave in
scJohn 11:01 ok, pushed those spaces in.
FB_GitHubBot 11:01 FireBreath: master Richard Bateman * 2974b3a (7 files in 6 dirs): Fixed build issue in vs express
FireBreath: master Richard Bateman * ac3e123 (1 files in 1 dirs): Fixed intermittent crash on IE
FireBreath: master Richard Bateman * f251375 (1 files in 1 dirs): Further work on fixing intermittent crash on IE
FireBreath: master Richard Bateman * cb447b2 (1 files in 1 dirs): One more IE crash that I missed
FireBreath: master Richard Bateman * 6bb8c79 (1 files in 1 dirs): Fixed issue #129
FireBreath: master Richard Bateman * ae80d55 (9 files in 7 dirs): Merge branch 'firebreath-1.4'
FireBreath: master Richard Bateman * 3601369 (0 files in 0 dirs): Imported patches from jtojanen
FireBreath: master commits 7566bcb...3601369 - http://bit.ly/dGJ0jl
taxilian 11:01 jtojanen: so it does get called in the firebreath-1.4 branch, but not in master; so I must have broken something
taxilian 11:01 brb
taxilian 11:01 jtojanen: so the 1.4 branch seems to shut down correctly now (or at least closer), but I seem to have broken something wtih my changes in master
but then class started and I haven't had time to compare things
jtojanen 11:01 the commit that has the fix is missing from master
taxilian 12:01 let me double check
this is weird, but you seem to be right
I merged 1.4 into master after it was there...
jtojanen 12:01 no you merged before according to the github network graph
taxilian 12:01 huh
FB_GitHubBot 12:01 FireBreath: master Richard Bateman * 435b0da (2 files in 1 dirs): Merge branch 'firebreath-1.4' - http://bit.ly/fgDk2n
taxilian 12:01 I'll try that now =]
hang on, though, I have a presentation I need to do
darn college
jtojanen 12:01 okey later then
taxilian 12:01 I'll check it in 15 min or so
FB_GitHubBot 14:01 FireBreath: firebreath-1.4 Richard Bateman * a34022f (1 files in 1 dirs): Merged fix from scjohn - http://bit.ly/haJCY0
scJohn 14:01 taxilian, did you actually merge that from my fork, or just edit the file? I ask just to expand my knowledge of git and how it records the changes.
taxilian 14:01 I cherry-picked the commit, actually
scJohn 14:01 ok
taxilian 14:01 and then I had to fix a conflict
I could hypothetically have pulled it from your fork, and would have if the branch I was on hadn't diverged
scJohn 14:01 i figured my commit messages would flow through.. not a problem, just trying to see how it works.
taxilian 14:01 yeah, it normally does, but not with cherry-pick, I guess
scJohn 14:01 i see
taxilian 14:01 sorry :-/
scJohn 14:01 i don't care.. git is a mysterious beast that I am trying to understand.
taxilian 14:01 hehe. have you read through http://progit.org/book at all?
scJohn 14:01 yes, i use git and svn on a regular basis, but i can't get out of the svn mindset
taxilian 14:01 ahh
scJohn 14:01 took me a while to figure out the 'best' way to integrate both your branch and 'my' branch.. finally got it working
wonder how that cherrypick will work...
taxilian 14:01 ahh
well, when you merge it back it should detect that they are the same change and not conflict, I would expect
scJohn 14:01 "Merge made by recursive" whatever that means.
taxilian 14:01 I'm still working on finding the best inter-branch merging techniques myself
scJohn 14:01 took me a while but i figured out how get both in there.. not that i expect to have a need for a fork
taxilian 14:01 well, it gives you an easy way to send me changes
scJohn 14:01 so how did your 1.4 branch get diverged?
taxilian 14:01 that can be nice
scJohn 14:01 yea
that is the power of git
taxilian 14:01 I applied several changes from jtojanen
scJohn 14:01 ok, in the future I will be happy to do any merges that are needed before you accept changes.
not that this was a big change
taxilian 14:01 okay
yeah, that's why I didn't worry about it
git pull —rebase is really nice for that, btw
just have to make sure you don't do that after someone has cloned from you
scJohn 14:01 that is where i get into problems
taxilian 14:01 yeah; I'm really really careful doing anything like that on the main repo
that's why I have a fork as well :-P
scJohn 16:01 taxilien, is there any hope for getting the installer to build with express?
taxilian 16:01 scJohn: I know more or less what needs to be done, if you want to fix it
I just haven't had time
scJohn 16:01 i'll be glad to
taxilian 16:01 basically we need to check the name of the process in DllRegisterServer and not set the per-user if it's heat.exe
hackish, I know
but the only thing I can think of
can't remember who suggested it
scJohn 16:01 that is why i am getting this errro?
Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe"
taxilian 16:01 heat fails to run
because the registry redirect in that version of ATL requires tricks that aren't compatible wtih it
scJohn 16:01 ok, may be over my knowledge. any idea what file i start in?
taxilian 16:01 FireBreathWin.cpp
in ActiveXCore
scJohn 16:01 oh, i figured this was a build thing
ok
taxilian 16:01 unfortunately no
scJohn 16:01 ok, maybe later tonight. off to coach 6yr olds basketball
taxilian 16:01 sounds fun =] wish them luck for me
starakaj 17:01 hi all
anyone feel like helping me get unstuck?
oh, nvm
hold that though
*t