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

IRC Nick Time (GMT-7) Message
mital 02:01 hi.. i have checked out the firebreath... trying to compile the same on windows xp - sp2, vs2005 sp1 ... I am getting various errors related to atlcom.h
can anybody help me
taxilian 09:01 morning all
kylehuff 09:01 morning
taxilian 09:01 how're stuff?
kylehuff 09:01 stuff are ok I guess
taxilian 09:01 better than stuff being lowsy
kylehuff 09:01 agreed. did you kick the flu yet?
taxilian 09:01 mostly
the cough is still with me; trying to decide if it's still partially a flu cough or just my asthma cough now
kylehuff 09:01 yeah, I have managed to avoid the flu for 3 years now.. which means it might be hardcore when it finally catches me..
taxilian 09:01 hehe
it's been a very long time since I've been out that much
out that hard
http://calendaraboutnothing.com/~taxilian see? I even missed a day of committing to FireBreath
kylehuff 09:01 your geek card is hereby revoked...
taxilian 09:01 nooooo!!!! *sob*
alright. so you wanna take over as primary FireBreath maintainer, then? ;-)
kylehuff 09:01 yeah, sure, lets do that.. *pulls out c++ for dummies*
iaincollins 09:01 taxilian: blegh! get well soon :)
taxilian 09:01 =] I must have gotten it from you, iaincollins: didn't you say you were sick over the holidays?
iaincollins: do you mind if I blatently steal some of your code from the log viewer for use in fbgen_web?
iaincollins 09:01 go for it :)
taxilian 09:01 cool =] thanks
you're much better at layout than I am
I'm more of a backend guy, I guess
iaincollins 09:01 Yeah I had it :-( (like 2.5 times)
taxilian 09:01 see? you gave me this flu. over, um, twitter, I guess
iaincollins 09:01 Hehe, yes, must have gone viral and been retweeted...
taxilian 09:01 lol
iaincollins 09:01 I got a friend to give me daily channel logs for the freebsd channel going back every day to 2004... so I'm using that to quickly sort out the optimisation and catch any weird bugs :)
taxilian 09:01 nice
I still look forward to poking through the code :-P
I'm really excited to get this up. it is my hope that it will be very helpful here
iaincollins 09:01 I won't go on about it, but just FYI.. regarding the index, the script doesn't actually use a DB... and it's not because I'm SQL averse or anything :-)
taxilian 09:01 what did you use?
iaincollins 09:01 it uses strpos with fast matching to find references quickly, with a regex to parse filenames and timestamps on lines (allowing for various popular log formats and filenane formats
(e.g. so it normalizes the dates from "freebsd-2010-12-31.log" or "#firebreath_20110130.log", etc)
taxilian 09:01 huh; makes sense, I suppose
it does that every time it does a search?
iaincollins 09:01 (line by line parsing, so not loading all of a file into memory at once)
yeah
taxilian 09:01 huh. interesting
iaincollins 09:01 it's a bit slower just now because it's parsing every file every time there is a conversation match
taxilian 09:01 now I really look forward to looking at it =]
iaincollins 09:01 but I'm just optimising that with the lots-of-log-files and should be fine :-) would love to be able to keep it like that (with some on the fly preferences saving maybe, for features like conversation saving)
just because unzip-and-go is very user friendly :-) (if it pans out as being feasible, which I think it is)
taxilian 09:01 hey, I'm all for trying it; it seems to work pretty well so far
I was thinking more of a combination of mysql and solr, but I'm flexible; I'm actually using couchdb for most of the stuff on that server
iaincollins 09:01 the code is pretty verbose, but is just 4 classes, only total of about 500 lines tops
taxilian 09:01 cool
iaincollins 09:01 yeah I was thinking SQL, but this actually seems like it might be scalable (using ./servername/channel/*.log as the path to log files, so searching a channel at a time)
anyway, I'll shut up about that now :-) just to answer any questions you might have had
taxilian 09:01 seems like you could probably dump it into sql later if need be
so just let me know when you feel like it's ready to put up on logs.firebreath.org
iaincollins 09:01 yeah, I worked how I think I'd do SQL on my iPhone on the commute in the other week, just to get it down
okies, will be this week
pq_ 09:01 hello
iaincollins 09:01 hi pq_
taxilian 09:01 howdy
pq_: any questions about anything? tried FireBreath yet?
pq_ 09:01 yeah
taxilian 09:01 do I know you already and forgot? =]
pq_ 09:01 it's cool
no we don't know each other I think
taxilian 09:01 iaincollins: another option would be to use couchdb and couchdb-lucene
pq_ 09:01 I'm trying to pull out some trick using DOM::Node
taxilian 09:01 well it's good to meet you, then =] I always enjoy meeting someone new using FireBreath. it makes my head swell and helps feed my delusion that FireBreath is a growing project ;-)
okay
iaincollins 09:01 taxilian: yeah I've been thinking about looking at couchdb, don't know couchdb-lucene will check it out
taxilian 09:01 iaincollins: you are familiar with what lucene is?
iaincollins 09:01 no, it rings a bell though
taxilian 09:01 iaincollins: it's the java full-text search engine that apache solr runs on; couchdb's major drawback is that it lacks good search capabilities
pq_ 09:01 I wonder if there's a way to know a node's coordinates (and size) relative to the plugin's
taxilian 09:01 so you can tie it to couchdb-lucene to get better search
pq_: the answer is definitely "maybe kinda sorta"
so the trick is that finding the actual pixel coordinates of something on a page in javascript it hit or miss
there are various CSS things that will mess up the calculation
let me see if I can find you some examples, though
pq_ 09:01 kinda sad
taxilian 09:01 very sad, actually
looks like this basically covers the calculation: http://www.quirksmode.org/js/findpos.html
you'd do it the same way using the DOM methods that you would in javascript, but you can do it in C++
just make sure you're on the main thread
pq_ 09:01 that looks handy
I just have to sum relative position to parent
taxilian 10:01 pq_: that's the gist. when you get a working code sample, if you don't mind contributing it, I may just tie it into the DOM::Element class
I had one in a previous life, but I lost that code when I left the company
and I haven't needed it since
pq_ 10:01 i'm trying to provide a javascript api to allow overlapping of DOM elements to plugin
iaincollins 10:01 pq_: This probably isn't very helpful
pq_ 10:01 why?
iaincollins 10:01 but, if it's applicable/possible in your case, you could maybe have everything inside a <div>
pq_ 10:01 yeah that's the idea
iaincollins 10:01 (with postion: relative or position: absolute on it)
then everything could be position: relative inside the div
pq_ 10:01 yeah, but plugin object doesn't support z-ordering
iaincollins 10:01 which would make alignment easy
pq_ 10:01 it means any <div> or similar is renderized below the plugin windo
window
iaincollins 10:01 oh I see what you mean
pq_ 10:01 to make it work, the plugin have to be notified of the <div> position
and avoid drawing in that rectangle
iaincollins 10:01 I was thinking you wanted to move elements like <div> on top of a specific area of the plugin, but I guess you want to draw them inside the plugin area
pq_ 10:01 well, you can't have elements over plugin
but you can make it look like they are
by drawing a plugin with a hole
and having the DOM elements below it
iaincollins 10:01 have you considered a windowless plugin (which can use z-odering)? that too slow?
(am just curious)
pq_ 10:01 that would be too much a hassle in my case
iaincollins 10:01 is it sucky for drawing?
ask am just keen to understand more about pitfalls/issues
-ask
pq_ 10:01 i'm not starting a plugin on it's own
i had a window application
iaincollins 10:01 oh
pq_ 10:01 trying to port it as a plugin
so anything is using HWND everywhere
iaincollins 10:01 oh I see.... have I see you on the mailing list posting about that maybe? :)
pq_ 10:01 guess not
but i think it's a common issue
iaincollins 10:01 oh! heh am sure someone else was doing that
hmm yeah, guess so
for you, is the benfit you can integrate your app with a webapp more?
taxilian 10:01 yeah, the only good way to support z-indexing is with a windowless plugin
but let me know how that goes
pq_ 10:01 i read somewhere it was the same approach used on Shockwave
taxilian 10:01 windowless can be a pain; main difference is you get a HDC to draw into instead of an HWND and you have to draw when the browser tells you instead of whenever you want
interesting; like I said, please let me know how it goes for you
I was not under the impression that you could tell the window not to draw in specific rectangles, but that the whole rect would just always be over the top of the browser window
pq_ 10:01 in my case it would be more of a problem since i have to do opengl graphics
taxilian 10:01 but I may well be mistaken
yeah, that's a trick
pq_ 10:01 and you can't create an opengl context just in any hdc
taxilian 10:01 the only way to do that with windowless is to render offscreen and then blit with GDI, which is slow
pq_ 10:01 yeah it would suck
if I manage to finish this one i'll share code
taxilian 10:01 cool
pq_ 10:01 i'm leaving see you next time
thanks for help
paztulio 13:01 have you recently tried browserstreams on chrome/linux?
taxilian 13:01 I have not
what issue are you having?
paztulio 13:01 the streamhandler is created and immediately destroyed afterwards
taxilian 13:01 are you holding a reference to the shared_ptr?
paztulio 13:01 if i look at the network-tab in the debugger, the request is there, but no response / content
taxilian 13:01 are you holding a reference to the shared_ptr?
if you don't, it will cancel the request as soon as the handler goes out of scope and is destroyed
paztulio 13:01 I adopted it from FBTestPlugin::testStreams()
so it should be correct, right?
I also tried adapting testStreams() to do some logging. onStreamDataArrived() is never called
taxilian 13:01 no, testStreams doesn't hold onto the shared_ptrs created for the handlers
try using AsyncGet
and see if that works
paztulio 13:01 I will try, thanks
taxilian 13:01 if AsyncGet doesn't work, it's a bug; let me know
amackera 13:01 taxilian: Where should I merge the coordinate system changes I'm working on? 1.4 branch?
taxilian 13:01 put it into master while we look at it and then we'll merge it to 1.4 if it's ready in time
did you see the refactor I did on the pluginwindow objects?
there were some inconsistencies
amackera 13:01 Cool I'll check it out
FB_GitHubBot 14:01 FireBreath: firebreath-1.4 Richard Bateman * 5211895 (5 files in 5 dirs): Fixed issue #136, duplicate windowless functions - http://bit.ly/hduUmw
amackera 14:01 Looks good :) I'm glad you've been able to look over my code
taxilian 14:01 well, there is someone actually using it now =] I think we've gotten most of the things, but I am a little concerned about the way that some of the mouse coordinates are set up
you know that you can have negative window coordinates if the primary display is not the topmost or leftmose?
leftmost?
amackera 14:01 Hmm
I was not aware
That's definitely not a good thing
taxilian 14:01 it can be problematic at times
I'm actually not 100% certain exactly how it comes through
but it's definitely worth watching
amackera 14:01 I'll dig a bit and see if I can come up with something better
taxilian 14:01 cool. one way or another, we'll come up with something
I'm just identifying the potential issues
amackera 14:01 The coord stuff is pretty flakey, especially the carbon stuff
mouse move events are pretty much a total hack
I think the Cocoa mouse things should be okay, the coordinates are given to us from the browser directly
taxilian 14:01 there is a check in cocoa right now where it says something about "if < 0, x = 0"
something like that
FB_GitHubBot 14:01 FireBreath: master Anson MacKeracher * dbc2ebb (2 files in 1 dirs): Plugin coordinate space change for Mac OS X ... - http://bit.ly/g83I4C
amackera 14:01 So right now the coordinate space status is top left for everything except windowed plugins in MS windows
taxilian 14:01 windowless plugins on MS windows are anybody's guess
at least on IE :-/
but okay
amackera 14:01 windowless ones are top left, for NPAPI anyway
taxilian 14:01 IE they vary; the coordinates are relative to the browser window, it would seem, but that actually seems to change depending on the draw call
it's really weird
amackera 14:01 hm, weird
amackera 18:01 taxilian: is logging still working in current master?
taxilian 18:01 amackera: I think so
it's improved somewhat
but that does mean changed
amackera 18:01 i've got add_firebreath_library(log4cplus) in my PluginConfig.cmake
taxilian 18:01 you need to add some methods to your factory
amackera 18:01 Ah
taxilian 18:01 see https://github.com/firebreath/FireBreath/blob/master/src/PluginAuto/log4cplus/log4cplus.cpp#L46
getLoggingMethods
you return a list of log methods to support
the options are file and console
if file, you should return the filename to log to
amackera 18:01 I see, thank you sir!