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

IRC Nick Time (GMT-7) Message
amackera 08:09 taxilian_away: as per the newsgroup post it looks like specifying the arch in prepmac is a little confusing
i'm not sure how to do it in cmake (in perhaps the projectDef.cmake)
taxilian 08:09 amackera: yeah, I was thinking about that too
I have to agree with them
I had a thought, though; hypothetically, if the libraries are built using the universal, then you could still build an X86 and link against them for the project, right?
amackera 08:09 yeah certainly
taxilian 08:09 lol. ok, some of these are pretty funny:
well, if that's the case, then we could probably put a set (CMAKE_OSX_ARCHITECTURES i386) in pluginConfig.cmake and it might just work
because it would override the default just for that project
amackera 08:09 i tried that previously and it didn't seem to work
but it's totally possible that i was "doing it wrong" as they say
i'll try to figure it out once i get a chance
taxilian 08:09 ok; I may look at it as well. I need to spend some time on homework, though
how heavily do you think the JSAPI_DOMDocument and related abstractions are used?
amackera 08:09 i happen to use them quite heavily
they are pretty useful
taxilian 08:09 how annoying would it be for you if I were to redo them somewhat? I want to move them into a JSAPI::DOM:: namespace, for one
amackera 08:09 go for it
taxilian 08:09 honestly, I have no idea why I didn't just do that to start out with
amackera 08:09 yeah it makes sense
taxilian 08:09 I must have been running on too little sleep
amackera 08:09 lol i know that feeling :P
taxilian 08:09 I feel like the last comment from that link I sent a minute ago:
//When I wrote this, only God and I understood that I was doing
//Now, God only knows
amackera 08:09 lol
* For the brave souls who get this far: You are the chosen ones,
* the valiant knights of programming who toil away, without rest,
* fixing our most awful code. To you, true saviors, kings of men,
* I say this: never gonna give you up, never gonna let you down,
* never gonna run around and desert you. Never gonna make you cry,
* never gonna say goodbye. Never gonna tell a lie and hurt you.
taxilian 08:09 =]
amackera 08:09 lol
taxilian 08:09 yeah, some of those are pretty good
//somedev1 - 6/7/02 Adding temporary tracking of Logic screen
//somedev2 - 5/22/07 Temporary my ***
amackera 08:09 baha
taxilian 08:09 so here is my thinking
there are a lot of things that IE doesn't let you do through IDispatch
but most of those are on the document or the window
so I'm thinking of making virtual classes for the DOMDocument stuff so I can override them on ActiveX
and implement things like getElementsByTagName in a browser-specific way when needed
amackera 08:09 seems reasonable
i really haven't worked with IE very much
taxilian 08:09 'cause that's definitely a better place for them than on BrowserHost
taxilian 11:09 have I ever mentioned how much I dislike troubleshooting templates?
taxilian 13:09 I just about have my refactor of JSAPI_DOM objects done
it is *much* better, IMO
but it is a definite significant breaking change for anyone who is using them
shouldn't be a difficult update, however
hey, WarGloom
taxilian 13:09 alright; the DOM refactor is essentially complete and is in Dev
I'm not going to put it in stable until we're closer to 1.3
so anything that needs to go in a 1.2.x release will go into stable
and get merged to dev
amackera 17:09 cmake --build doesn't really give a very comprehensive error report
cygmatic 17:09 wasn't there a "verbose" flag added?
amackera 17:09 maybe that's the problem, the error reports are lost amongst the noise
cygmatic 17:09 i thought it was less verbose by default?
ah, found it: passing -DVERBOSE=1 to the prep-script overrides it
(we really have to document those)
taxilian 19:09 cygmatic: what, you're saying that the arbitrary decisions that I make like changing verbosity and adding flags should be documented somewhere?
cygmatic 19:09 taxilian: ok, crazy idea - i know
taxilian 19:09 I guess as long as you've started the page, though, we could try to keep it up to date ;-)
did you look at the DOM object refactoring that I did?
cygmatic 19:09 not yet, should i?
taxilian 19:09 I'd be curious if you have any feedback
even just against the general idea
it seems much less "hackish" than putting things on the BrowserHost
cygmatic 19:09 i definitely prefer DOM::foo over DOM_foo, if you mean that
taxilian 19:09 that is the first part =]
not sure why I didn't do it that way to start out with
also, I have made IE specific versions of those objects
to provide special handling of getElementsByTagName, etc
cygmatic 19:09 looking at it, wouldn't that lead to problematic situations when i create a DOM::Window from an object i get passed from the script?
i.e. wouldn't we need a factory method for those?
taxilian 19:09 why would you create a DOM::Window with an object passed from the script?
cygmatic 19:09 just taking an arbitrary example
taxilian 19:09 I guess I'm working on the assumption that you would only get the window from the BrowserHost
cygmatic 19:09 yep
taxilian 19:09 however, the DOM::Window would still work as JSAPI_DOMWindow would have previously
cygmatic 19:09 i think its a bit surprising if it suddenly breaks when not using it
if making the constructor private and using a factory function returning those specialized versions, it would be completely transparent
taxilian 19:09 so anything you pass in from the DOM (an iframe? not sure what else you'd ever pass in that way) that you create by hand will still work with anything allowed via IDispatch
cygmatic 19:09 eh, opaque i mean
taxilian 19:09 Can you give me a specific use case to help me understand the problem better?
cygmatic 19:09 lets not look at window specifically, but at say arbitrary dom nodes and assume we might need to add more workarounds
taxilian 19:09 hmm. Okay, I can see your point there
cygmatic 19:09 whenever a user retrieves such an object from anywhere else... :/
taxilian 19:09 hmm. Yes, indeed. So where do you recommend putting the factory methods?
seems like the only place we have enough information to do it...
cygmatic 19:09 i'd put them in the respective classes
they can still forward to browserhost if needed
taxilian 19:09 FB::DOM::Element::createFrom(jsobj);
cygmatic 19:09 hm, or are they missing information like the host in some cases?
taxilian 19:09 well, yes and no
they don't have nearly enough information to do the actual creation
cygmatic 19:09 or just create() with the appropriate overloads :)
taxilian 19:09 since they are supposed to be browser agnostic
they could just get the host off of the JSObject
and then call a factory method on that
that would do the actual creation
kinda oblique, but would appear to the user to be on the right object
cygmatic 19:09 at least i think it is more natural to use Element::create(jso) than host->createElement(jso)
taxilian 19:09 yeah, I tend to agree
though it's a bit confusing behind the scenes
since Element doesn't actually know what browser we're on
so the Element would still be calling host->createElement or some such
cygmatic 19:09 ok, but at least its nicely wrapped? :)
taxilian 19:09 hehe
yeah, that's doable
taxilian 19:09 so should I just make those public methods on the host?
so you could actually do it that way?
the only other option I see is to make those all friend functions...
friend classes
guess I should mention cygmatic so your client notifies you I'm asking you a question… :-P
cygmatic 19:09 huh, help, what? ^^
taxilian 19:09 when I call FB::DOM::Element::create(..)
it will then call something on host
or host->_createElement(…) if we want to make it clearish that it's not normally supposed to be called directly
but if I make it protected, I have to make all the DOM classes be "friends"
and if I don't, then there are two ways to do the same thing
which is preferable?
cygmatic 19:09 for the record, you don't have to make them full friends:
i consider full friendship if you only want access protection to certain functions rather destructive
but i don't know, i think not having two ways would streamline things
and avoid having to support two ways
taxilian 19:09 hmm; I'm not sure I understand exactly how that works.
cygmatic 19:09 oops, here is more explanation:
taxilian 19:09 so basically I create a special "SomeKey" class?
cygmatic 19:09 it has the major advantage that you don't have to give access to everything
taxilian 19:09 that could be potentially confusing to users, however;
cygmatic 19:09 even if they are commented as "// internal, not for you" in the class declaration?
ah well, not a must have - just consider it an FYI
taxilian 19:09 yeah, I guess that would help :-P
so I guess I could create a "DOMProtected" class and make both BrowserHostWrapper and DOMNode friends
cygmatic 19:09 (c++ and overuse of friendship - one of my pet peeves)
taxilian 19:09 hmm. I'm thinking this may be more trouble than it's worth
cygmatic 19:09 you'd only have to make the callers friends
taxilian 19:09 ti's giving me a headache =]
tell you what; I'll create the factory methods
you can protect it if you'd like :-P
cygmatic 19:09 heh, ok
taxilian 20:09 actually, this gives me an excuse to refactor something I wasn't fully happy with
cygmatic 20:09 this reminds me - would it maybe make sense to try to limit bigger interface changes to second position version number changes (e.g. 1.2 -> 1.3)
taxilian 20:09 yes
this change is scheduled for 1.3
not 1.2.1
which means that changes scheduled for 1.2.1 should go in default
not in dev
cygmatic 20:09 ah, great
taxilian 20:09 There are two nightly builds now
dev and stabel
this is exactly the type of thing I wanted to create dev for
it's there where it can be tested, but we can still finish 1.2.1 in the other clone
cygmatic 20:09 and someone will pull specific changes or the head from dev when it should go to default?
taxilian 20:09 yeah
I think there is a way to do that using hg
if not, we could do it by hand
my hope is to just avoid that problem :-P
but we'll see
it may take some trial and error
cygmatic 20:09 oh, ommiting the build-dir and passing args for the prep-scripts doesn't actually work - e.g. ./ projects/ -DVERBOSE="1"
taxilian 20:09 yeah
I know
I don't know of a way to fix that
ok, new problem
cygmatic: FB::DOM::Window is actually a typedef
for shared_ptr<WindowImpl>
for clarity
so I can't do FB::DOM::Window::create
what would you think about doing FB::DOM::createWindow(...)
cygmatic 20:09 why is it called WindowImpl?
i.e. why is not actually FB::DOM::Window?
taxilian 20:09 so that FB::DOM::Window could be the shared_ptr
cygmatic 20:09 ah
taxilian 20:09 having a copy constructor on some of the ActiveX stuff would be somewhat of a pain
cygmatic 20:09 and you don't like actually calling them WindowPtr etc.?
taxilian 20:09 I guess we could go to that
but it just seems like a pain
might be more clear
dunno. conflicted
what are your thoughts?
kalev, nirvdrum, nitrogenycs, you guys around and want to comment?
cygmatic 20:09 hm, personally i find *Ptr clearer as it conveys that it actually is a reference, not an instance
taxilian 20:09 yeah, you may be right about that
I guess it's not that hard to change
cygmatic 21:09 taxilian, i think this should handle the prep-args:
taxilian 21:09 looks great; as soon as you can find a way to do that in windows, we should be set
cygmatic 21:09 what, me and batch files? *g
taxilian 21:09 sorry, I should have been more specific earlier about why I didn't know a way to fix it
in bash, that's relatively easy (or at least doable)
on windows, I haven't a clue how to do that in a batch file
cygmatic 21:09 aha
taxilian 21:09 I guess we could do it in the bash scripts anyway
it doesn't break backward compatibility, right?
cygmatic 21:09 oops, has a problem with examples
regarding breaking, i don't think so - but then thats why i asked
taxilian 21:09 I'll have to look at it more closely later; I'm trying to finish the changes to the DOM classes tonight
but in general principle it looks like it ought to work
default behavior now is to use "projects build"
and if you specify examples, to use "buildex" as the missing param
since that's so fundamental to what people use, I'd rather not break that without a really good reason; we've already changed enough things lately to frustrate people
cygmatic 21:09 yeah, i tried to model that
taxilian 21:09 I'm tempted to make a "2.0" prep system, though; create some small C helper progs to make it possible to do what we need on windows in a batch file
cygmatic 21:09 will update in a bit
taxilian 21:09 and move everything to a single prep script or prep.cmd
store defaults in a file in the current dir or something
cygmatic 21:09 i might look at the cmd before we start adding a boost-strapping phase
taxilian 21:09 so the next time you use it, it does the same as last time
cygmatic 21:09 hm, that would be nice though
taxilian 21:09 then just prompt "Do you want to make a: 1) VS2005, 2) VS2008, 3)...
take all the guesswork out of it
I think it would be easy enough to do with some simple C scripts added onto batch
and those could be stored in the repo
problem is, I don't really have time to do it
it's not important for work
so I can't justify doing it on Facebook's time
taxilian 21:09 cygmatic: I like the factory idea, now that I've started playing with it; it's a lot cleaner than the other way I was doing it
and it allows me to reuse more code
and I have reluctantly decided you're right about the Ptr naming and have changed it accordingly
see, this is why I like to have someone review my code =]
cygmatic 22:09 second set of eyes is always helpful :)
taxilian: if you have time, gives this version a test:
(bash is a strange language)
taxilian 22:09 this is a replacement for
cygmatic 22:09 for the start of it
i don't care about the part after it prints the dirs
taxilian 22:09 lol
so I can keep both lines there? =]
actually, the shift 2 could potentially be problematic for you
cygmatic 22:09 oh, right
that many lines *g
they come after that stuff
taxilian 22:09 you know what shift 2 does?
$3 becomes $1, $4 is $2, etc..
loses $1 and $2
cygmatic 22:09 oh wait, why didn't that break before? ^^
taxilian 22:09 dunno
I was wondering if I was missing something very clever that you were doing =]
it would not be the first time =]
cygmatic 22:09 alright, something like this then:
taxilian 22:09 btw, if you haven't seen this yet, you need to:
hate to bring it up, but that breaks if there are no args to shift
cygmatic 22:09 besides the $ i forgot it looks fine to me?
taxilian 22:09 ahh, yes, you are correct
I should have spotted that
cygmatic 22:09 i should have mentioned that ^^
for reference:
taxilian 22:09 seems to work well for me
I say put it in dev
that way we'll get some more testing on it before it goes into a release
cygmatic 22:09 ok
taxilian 22:09 I also tested it out of directory and that works too
(i.e. ../firebreath/ ../firebreath/examples buildDir)
that was really fun to get working on windows, btw… :-P
cygmatic 22:09 oh, i don't really wanna know the details :/
taxilian 22:09 hehe
btw, have you ever heard of ZNC?
cygmatic 22:09 no, whats that?
taxilian 22:09 it's kinda an IRC proxy
you connect to a ZNC server and it connects to IRC
then when you disconnect, it marks you as away and records anything that happens while you're gone
sends you the playback when you sign in again
there are a lot of plugins for it that let you do different things
I use it and it's great; I'm always the same username, no matter which (or how many) computer I'm on
cygmatic 22:09 hm, interesting
taxilian 22:09 one of the plugins, log, is what is logging all activity in this channel
I should probably make that available somewhere
anyway, if you want I could set you up an account on my znc server sometime
cygmatic 22:09 i had irssi running continuously as i used irc more, but decided that i need to care less about being connected ;)
taxilian 22:09 for me it's very useful, since it lets me have more of a presence in this room
and see what is going on when I'm away
cygmatic 22:09 thanks, but i'll pass for the moment
taxilian 22:09 ok
taxilian 22:09 ooh, stumbled across a fairly severe IE bug with the new message window thing
it only worked the first time. Refresh the page and the whole thing is toast
the message window doesnt' get created
cygmatic 22:09 huh
taxilian 22:09 because it tries to re-register the window class
with the same name
should be an easy fix
cygmatic 22:09 ah, phew
taxilian 22:09 just make the ATOM static
by definition, these will all be running on the same thread, so don't have to worry about thread safety
cygmatic 22:09 it sounded like it was one of those really mysterious bugs
taxilian 22:09 it was, briefly =]
but fortunately not too bad
taxilian 22:09 and I should be able to backport that to the main branch without any problems