| |
| |
| |
|
Page: 1 2 3
<compnerd> ecoffey: was wondering if you already had an idea for how you want to expose the Gaim API
<compnerd> ecoffey: or if not, if you want to discuss one possible way
<ecoffey> what grim (one of the devs) suggested was having a bunch of xml files and autogening the c# cl***es out of that
<Paco-Paco> why xml?
<compnerd> Paco-Paco: because you can attach metadata to the mthods, and thus be able to enable/disable as you go
<ecoffey> Paco-Paco: *shrug* it doesn't really matter what we use; the point is to not have to maintain a crapton of c# files, and to generate some of the goofy syntax things that are going to happen
<Paco-Paco> compnerd: oh, xml is the only way to attach metadata?
<Paco-Paco> too many people have only one hammer :-P
<compnerd> Paco-Paco: naw, but its the easiest
<ecoffey> the other half of this is writing the glue code so that the rest of gaim knows whats happening in plugins and vice-versa, and then plugging that glue code into the mono runtime
<Paco-Paco> I don't follow
<Paco-Paco> Gaim shouldn't have to know anything about plugins, it should communicate generically via signals
<ecoffey> Paco-Paco: oh; well like if a plugin prints into a conversation or something like that
<Paco-Paco> right, so C# wrappers for teh C api
<ecoffey> yeah yeah
<ecoffey> but thats where it gets tricky
<ecoffey> right now when a signal (one of the two signals currently in the api) fires, the loader figures out what "objects" the callback expects (GaimBuddy, GaimConversation, etc); the loader creates a .net object from that c struct, and then p***es in the object to the .net callback
<compnerd> hmm...
<Paco-Paco> yeah, that's what Tcl does, as well
<Paco-Paco> and it's ugly as hell
<ecoffey> but that .net callback needs to be able to modify the original c struct, which would be wrapped up in methods and properties, but at some point it'll hit c glue code again to do that
<ecoffey> yes
<ecoffey> yes it is
<Paco-Paco> particularly because you have no idea when those underlying objects might die or disappear
<Paco-Paco> and so allowing the plugin to keep handles to them violates people's expectations for a "safe" language
<ecoffey> yeah
<ecoffey> but its something we (i) need to implement somehow :-)
<Paco-Paco> yeah
<Paco-Paco> in Tcl I validate what structures I can
<Paco-Paco> often by walking a list of them, etc.
<Paco-Paco> accounts and buddies can be verified that way
<ecoffey> yeah
<ecoffey> if gaim was gobjectified then i could just set a handler on it when it gets destroyed, but alas it is not
<Paco-Paco> yeah
<compnerd> hmm...out of curiosity, why is it not?
<ecoffey> it just ain't, although one of the devs is working on it
<Paco-Paco> it predates gobjects
<ecoffey> that too ;-)
<Paco-Paco> gobjectification isn't always sufficient for Tcl, unfortunately
<Paco-Paco> due to "shimmering"
<ecoffey> shimmering?
<compnerd> Paco-Paco: "shimmering"?
<Paco-Paco> (objects can be flashed back and forth from a native representation of some sort ot a string which can be turned back into that object)
<compnerd> interesting
<ecoffey> crazy go nuts
<compnerd> sorta like serialization ?
<Paco-Paco> so you have to release the gobject or whatever when it's turned into a string
<Paco-Paco> and then re-find or acquire or create it or whatever when you go back
<Paco-Paco> it's a form of serialization, sure
<Paco-Paco> although it's often not useful as a serialization; it can't always be communicated or stored persistently or etc.
<compnerd> ah
<Paco-Paco> that depends entirely on the object in question, of course
<ecoffey> oh i see how you validate accounts and buddies and such in tcl
<ecoffey> the other thing is that the mono runtime spawns a few of its own threads at init, and i'm not 100% sure how they operate, as in does the c api block when you invoke a method and stuff like that
<KingAnt> Hmm, why is our silc PRPL called "libsilcgaim.so"?
<ecoffey> so modifying the c struct from the managed code, might cause a race condition; ick
<nosnilmot> KingAnt: to avoid it conflicting with silc-toolkit's own libsilc
<KingAnt> Ah, ok
<KingAnt> nosnilmot: I just tried building some Gaim 2.0.0 CVS RPMs and got the following error: File not found: /var/tmp/gaim-2.0.0cvs-root/usr/lib/libgaimperl.so
<nosnilmot> hmm. I'm actually working on the spec file at the moment, I'll take a look at that too
<KingAnt> nosnilmot: Looks like libgaimperl.so is now in /var/tmp/gaim-2.0.0cvs-root/usr/lib/gaim/
<KingAnt> nosnilmot: Oh ok. I just added --with bonjour? I bet that's going to conflict with everything you're doing
<nosnilmot> hah, I was adding '--with howl' :)
<KingAnt> Ok, cool
<KingAnt> So it won't conflict
<KingAnt> We'll just add them both
<KingAnt> (Yes, I'm joking)
<KingAnt> nosnilmot: You go ahead and do that, I'm sure you'll do a better job than I will
<nosnilmot> there was some talk of possibly supporting avahi too at some point, I thought if we had --with howl we could later add --with avahi too, either of which would produce a gaim-bonjour package
<KingAnt> That makes sense
<KingAnt> We should definitely support Avahi at some point. It doesn't matter to me if we continue support Howl, as well
<Paco-Paco> I love coffee
<grim> http://code.reaperworld.com/gaim/somethings_wrong_here.jpg
<grim> i'd like to know how that happened..
<Paco-Paco> what, how the window borders got so huge?
<grim> no look all my accounts are online..
<_Caleb_> thats happened to me
<grim> and my buddy list is completely empty and missing the handle in the bar
<Paco-Paco> everyone blocked you
<grim> Paco-Paco: that doesn't explain the widget problem :P
<Paco-Paco> picky picky
<_Caleb_> you know how you hit the arrow to hide users in a group?
<_Caleb_> well i did that and then went to show offline users
<_Caleb_> and when i went back to hide em the list went blank
<grim> well everyone is "offline"
<nosnilmot> do they actually show up if you display offline buddies, or are they totally failing to display? (I've seen some times when some buddies totally fail to display)
<_Caleb_> they display
<_Caleb_> but when i goto hide em the list goes blank
<grim> nosnilmot: yeah
<_Caleb_> but thats only if i hide the users in a group
<nosnilmot> grim: "yeah" ? to which
<grim> nosnilmot: yeah to turning on show offline buddies displays buddies that should already be showing
<nosnilmot> oh. do they display as offline (dimmed) buddies, or as online?
<grim> online
<nosnilmot> freaky odd
<grim> yeah
<grim> but i need to update and rebuild anyways..
<nosnilmot> the behavior of gaim_account_is_connected() has changed subtley, I do wonder if buddy_is_displayable() should be using !gaim_account_is_disconnected() instead
<marv> how do you guys get so much more done than me lately?
<grim> nosnilmot: well showing empty groups isn't showing those either..
<grim> they don't show until i show offline buddies
<nosnilmot> right - I'm a little concerned that all users of gaim_account_is_connected weren't carefully examined when that function changed from meaning 'account is not disconnected' to 'account is fully connected'
<grim> ah
<sadrul> iirc, i submitted #1243569 to fix this
<nosnilmot> iirc, you submitted the original patch that changed the behavior of gaim_account_is_connected too... :-P
<sadrul> yeah, and that one got committed, but not this one
<kffkcuicu> can't wait for gaim-vv (gaim 2.0.0) :\
<Alver> Too bad
<Alver> You'll have to :)
<kffkcuicu> i will
<kffkcuicu> 3.3gb left on the harddrive, not enough for a windows os
<sadrul> there's concern that -vv may not make it in gaim 2.0.0
<ecoffey> grim: you know how we discussed only having the mono runtime active when a plugin loaded? well mono definitely doesn't want to play nice on this issue...
<grim> ecoffey: heh, well i take a look at making that happen in a bit, but i'd be curious to see what you tried
<ecoffey> grim: i created a ml_init, and ml_uninit that started and stopped the runtime (and kept track of it running); so when i probe a plugin i call ml_init and when i'm done a i close the ***embly and call ml_uninit; that works for the first plugin i probe, but when i try to probe a second one the runtime freaks out, tells me that it a code section it shouldn't have, and aborts
<ecoffey> :-D
<Paco-Paco> can the monotone runtime be stopped and restarted?
<ecoffey> i'm beginning to think that it can't
<Paco-Paco> it may be intended to be started once and left running
<ecoffey> yeah it seems like to me...
<ecoffey> so the compromise might be to just keep ***emblies closed until a plugin is loaded
<Paco-Paco> are plugins loaded into individual sandboxes?
<Paco-Paco> (they should be)
<grim> ecoffey: well that can wait i'd like to see a bit more stability first anyways :)
<Paco-Paco> if so, I'd start the runtime once, and create and destroy sandboxes as needed
<ecoffey> grim: yeah; i was just bored ;-)
<grim> heh
<ecoffey> Paco-Paco: mono has a "domain", and you can load any number of ***emblies into that domain
<ecoffey> and when you init the runtime it returns out a domain
<ecoffey> grim: is it still freaking out on your side? 'cause it's all happy over here...
<grim> ecoffey: well i'm running my main instance with your latest patch..
<grim> although i really do not like that mono is handling our sigsegv, although i don't currently see a way around that..
<ecoffey> yeah; it doesn't support signal chaining or whatever
<ecoffey> and i'm not proficient enough to provide a patch ;-)
<Paco-Paco> most things don't
<Paco-Paco> because many platforms have historically not
<[set]> is -vv out?
<kffkcuicu> no :(
<kffkcuicu> wish it was
<ecoffey> well kids i'm off to food
<[set]> im 17 , im not a kid anymore
<[set]> my hearts been beating for 17 years
<Paco-Paco> haha
<[set]> has anyone bought sean's book?
<[set]> i will get my hands on it soon sometime
<charkins> [set]: i picked up a copy
<seanegan> I've got, like, a bunch.
<[set]> send some , that 'll be great :) hahaha
Return to gaim
or
Go to some related
logs:
football
windowsxp
beginner
poker
rock
politics
|
|
