IRC Log Viewer » #firebreath » 2010-09-27

IRC Nick Time (GMT-7) Message
amackera 08:09 hello all
cygmatic 08:09 hi
taxilian 08:09 morning
amackera: whats the verdict on issue #74?
looks like you're on it =] thanks
amackera 08:09 I'm just waiting for schnapple to submit his patch
brb mac os is bugging me to restart
lame
taxilian 09:09 I guess I need to finally track down the source of these unhandled exceptions :-P
it aparently isn't what I thought it was
cygmatic 09:09 shouldn't VCs "break on C++ exceptions" tell you rather quickly where it's coming from?
taxilian 09:09 that's my plan
just have to get it compiled first =]
I'm not expecting this to take me long
cygmatic 09:09 ah, what do you need it compiled for... real programmers just execute the source ^^
taxilian 09:09 lol
I'm lazy
and I have never claimed to be a real programmer
that's why nobody likes anything I've written ;-)
amackera 09:09 you've been faking it all this time!?
cygmatic 09:09 probably outsourced the actual implementation to some cheap sweatshop... ?
amackera 09:09 i knew your comments had an outsourced-to-india-esque feel to them
lol
cygmatic 09:09 *g
taxilian 09:09 lol
hey, it was good enough to get me a job at Facebook…. ;-)
taxilian 09:09 well, that was easy
just had to convert a cast<> to a convert_cast<>
hmm. but the message still shows up anytime the exception is thrown, even if it is handled
taxilian 09:09 so issue #75 about the exceptions being thrown? was not actually a bug
though I have improved it so that it doesn't happen so often
Visual Studio by default logs all exceptions thrown, even if caught correctly
which this exception was
amackera 09:09 can you mark something in gcode as not-a-bug?
taxilian 09:09 yeah
but I'm going to mark it as resolved
because the exception in question should be gone now anyway
I improved the checking on the asyncLog
and there was actually a bug I found and fixed that was also throwing an exception that was a real bug
just not what he was complaining about
=]
amackera 09:09 nice :D
taxilian 09:09 it probably wasn't something anyone would have reported
but it was a polish thing =]
taxilian 09:09 I am beginning to think it would be a good idea to split out the ActiveX and NPAPI projects
most of those two projects are generic to all plugins
with just a few parts that are specific
it really should be seperate, so that you don't have to recompile everything for every project when it's not needed
cygmatic 09:09 aren't they for the most part?
taxilian 09:09 actually, I think only a few files in each need to be project specific
certainly a lot of bits, like IDispatchAPI, the DOM objects, NPObjectAPI, etc, don't need to be
cygmatic 09:09 ah, you mean the FOO_NpapiPlugin etc.
taxilian 09:09 right
cygmatic 09:09 good point
but nothing absolutely pressing
taxilian 09:09 true
taxilian 10:09 amackera: not trying to push, just trying to plan: ETA on issue 74?
taxilian 11:09 anyone know what the windows version of "__BEGIN_DECLS" is?
ahh, found it
amackera 11:09 taxilian: I'll try to quickly close issue 74 this afternoon
I have invalidating CA working also, i just want to test it out a bit before pushing to dev
taxilian 11:09 awesome!
put 74 in stable, if it's not too much trouble
I want to do one more bugfix release before 1.3
amackera 11:09 sure
taxilian 11:09 so Nikita has been doing some testing; it seems that the windows MultiByteToWide, etc functions don't work consistently correctly
so i'm getting the ones I use on unix variants to work everywhere
hoping that just solves the issue
taxilian 12:09 hmm. well, that doesn't work
windows wants 16 byte strings and unix is expecting 32 byte
therefore the function won't work on windows
wish I knew why WidecharToMultiByte wasn't working right
taxilian 12:09 amackera: if by change all of the drawing models are disabled in the configuration, will it work with no models? (i.e. no pluginwindow ever attached, etc)
cygmatic 12:09 taxilian: nikita didn't happen to have any test cases?
taxilian 12:09 he did, but I don't remember the specifics
it had to do with different encodings on the source file on windows browsers
I just shot him an email asking him to file an issue
cygmatic 12:09 hm, if the encodings come in wrongly (i.e. not utf-8), there is no way to know what it's supposed to be
taxilian 12:09 he had a case where it should have been able to tell
and it worked on unix
linux
just not windows
cygmatic 13:09 hm, interesting
taxilian 13:09 ever used escaped_list_separator with boost tokenizer?
cygmatic 13:09 nope
any specific trouble?
taxilian 13:09 just trying to figure out how to make it ignore empty entries
i.e. 2 or 4 spaces should be treated the same way
cygmatic 13:09 so just tokenizing by whitespace?
taxilian 13:09 whitespace and ","
I'm writing an assembler
seems easiest
cygmatic 13:09 tokenizer<char_separator<char> > tokens(text, char_separator<char>(" \t\n,"));
seems to do it
taxilian 13:09 the problem is that I need to be able to escape things with "
so I can't use char_seperator, since I'm already using escaped_list_separator
sorry, should have specified that explicitly
cygmatic 13:09 hm, i don't think it supports that
maybe you get there faster with spirit?
whatever your exact format is
the "Employee - Parsing into structs" example might be close to what you want
taxilian 14:09 well, I finally just wrote it to ignore the whitespace tokens
it's not worth spending the time to do it "right" on a school project
cygmatic 14:09 healthier approach than i have i guess
taxilian 15:09 cygmatic: sorry to keep asking you things =] do you know of a common (stl, preferably) data structure that is basically a priority deque?
(double ended queue)?
cygmatic 15:09 nope
and no problem
taxilian 15:09 cygmatic: so I finally ended up just making my own version of hte escaped_list_separator
that keeps the " " around quoted tokens
and discards duplicates
problem solved :-P
cygmatic 16:09 or that ^^
amackera 16:09 taxilian: as far as I can tell issue 74 is a non-issue
i can't reproduce it
I suppose the problem is that PluginWindowMacCocoa doesn't send a RefreshEvent when it gets a Cocoa DrawEvent
at least it does on Firefox
taxilian 16:09 it looks like his submitted fix would make sense, though; be more accurate
no?
amackera 16:09 it only works if the plugin sits at the top left corner of the page
taxilian 16:09 as per cygmatic's comment, that shouldn't be the case: https://developer.mozilla.org/en/NPN_InvalidateRect
the docs specify that it originates at the top left of the plugin
is that not what you're seeing?
amackera 16:09 hmm
i wonder why it requires a rect at all then...
maybe the draw event provides a rect to invalidate
cygmatic 16:09 because you might only want to invalidate partially
amackera 16:09 yeah looks like it does
ok i'll test it out see if that works
just need to finish this BS taxation thing for business guy
taxilian 16:09 lol. "Born free, taxed to death"
amackera 17:09 i wish i just had *time* to clean all this up :S
story of all our lives :P
taxilian 17:09 hehe
… that sounds eerily familiar =]
amackera 18:09 damn you guys are right
it's plugin coordinates
pushed fix to trunk, not dev
taxilian 18:09 yeah
I think you just pushed dev to trunk as well
pretty certain, in fact
not actually sure how to fix that
amackera 18:09 wo
shit
sorry :(
you're totally right
f*ck
revert?
if you have a local copy of stable you can push an overwriting change
ugh it was way to easy to screw that up
cygmatic 18:09 hg backout?
http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html
taxilian 20:09 hmm
how to best deal with this?
the easiest way, of course, would be to simply say that the next release will be 1.3 =]
taxilian 20:09 the repository is down for a few minutes while I fix things
I think next time I will do this a different way, however =]
taxilian 20:09 amackera: the push has been removed and I pushed it into dev =]
the easiest way to get that change into stable is probably to clone the trunk and then apply a patch from your changeset on the other one
and I have learned some new things today =]
amackera 20:09 sorry for all the trouble, taxilian
taxilian 21:09 it happens =]
and it is a real problem; I'm open to ideas on how we can prevent things like that
honestly, though, don't worry too much about it
I mean, try not to do it again and all that, but don't beat yourself up about it =]
… also, if you want to try to put your change back into trunk, but just that change, that would be cool too =]