Menu
▾
▴
gaim-bnet-devel — gaim-bnet Developers
You can subscribe to this list here.
| 2005 |
Jan
(72) |
Feb
(28) |
Mar
(15) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Zilo <ko...@gm...> - 2005-01-20 23:53:11
|
After reading gaim.sf.net/win32/build.php all is easier :) Anyway, I wrote the Makefile.mingw for our src directory, using the =20 gaim's ones as examples, and finally build a working libbnet.dll :) The only thingh to change in sources is the send(), that we can't find =20 in mingw header files, we should use write() instead (like the others =20 plugins do)... But... there's a 'but' :) The write() function always returns an error, EBADF (bad file =20 descriptor)... I still don't understand why :P I attach the small patch and the Makefile.mingw... if you want to try =20 by yourself. cya |
|
From: SourceForge.net <no...@so...> - 2005-01-19 09:57:06
|
Patches item #1105141, was opened at 2005-01-19 10:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=650116&aid=1105141&group_id=107748 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dario Zilocchi (evew) Assigned to: Nobody/Anonymous (nobody) Summary: Bad logins fix Initial Comment: I'm not sure it will work *ever*, just test it Diff contains also my last, not committed, updates :P ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=650116&aid=1105141&group_id=107748 |
|
From: Zilo <ko...@gm...> - 2005-01-19 09:19:11
|
On 01/18/05 17:08:27, Don Seiler wrote: > On 17:06 Mon 17 Jan , Gary Kramlich wrote: > [...] > > As for a release, that's up to don. :) >=20 > Such power! If it were up to me, I'd say we're pretty close. There > are those two bugs that I'd like to see tracked down. Actually I =20 > think the "crazy CPU" one was addressed by evew's flood patch. Yes, we didn't care of len=3D=3D0 in bnet_conn_input_cb() after the read(),= =20 so the code wasn't catching the disconnection, falling in loop... I didn't realize I catched the bug, cool :) > That still leaves the bad login one. Basically try to log in on a =20 > server with an account that doesn't exist on that server. Like I =20 > tried logging in with 'dtseiler' on europe.battle.net, or just make =20 > up a random account name to try. >=20 > Basically it will hang on "Waiting confirmation" for a while and then > say that you are Online, even though you aren't. You _will_ get PING > from battle.net server, but you won't be able to do anything or send > any commands. Yes, I'm thinking about this... maybe we can catch it with a timer, a =20 sort of "if welcome INFO isn't received until 15 secs after login, then =20 we aren't *really* logged in" Or we can set a max user/pass attempts... I see that for a real one we =20 need to retry only one time (even if I don't know why), else it'll need =20 several attempts before the "Waiting confirmation" will come... It doesn't sounds bad to me :) So, I'll code the last one and upload a patch... notice me if you login =20 with more then two user/pass attempts! cya |
|
From: SourceForge.net <no...@so...> - 2005-01-18 16:10:08
|
Bugs item #1104563, was opened at 2005-01-18 10:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=650114&aid=1104563&group_id=107748 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Don Seiler (rizzo) Assigned to: Nobody/Anonymous (nobody) Summary: Close chat/im conversations when log out Initial Comment: I logged out of my bnet account, but the public chat tab was still open. This should be closed. I'm not sure if this also happens for private IMs, but check to be sure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=650114&aid=1104563&group_id=107748 |
|
From: Don S. <do...@se...> - 2005-01-18 16:08:52
|
On 17:06 Mon 17 Jan , Gary Kramlich wrote: > Adding a limit of adding is fine. But we should not be polling. Just > make the server side list authoritive and be done with it. If someone > isn't on the server list but is on the local, remove them from the > local. I totally agree. We shouldn't be trying to do things that the official protocol doesn't support. > As for a release, that's up to don. :) Such power! If it were up to me, I'd say we're pretty close. There are those two bugs that I'd like to see tracked down. Actually I think the "crazy CPU" one was addressed by evew's flood patch. That still leaves the bad login one. Basically try to log in on a server with an account that doesn't exist on that server. Like I tried logging in with 'dtseiler' on europe.battle.net, or just make up a random account name to try. Basically it will hang on "Waiting confirmation" for a while and then say that you are Online, even though you aren't. You _will_ get PING =66rom battle.net server, but you won't be able to do anything or send any commands. --=20 Don Seiler do...@se... Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xFC87F041 Fingerprint: 0B56 50D5 E91E 4D4C 83B7 207C 76AC 5DA2 FC87 F041 |
|
From: SourceForge.net <no...@so...> - 2005-01-18 00:11:48
|
Patches item #1104294, was opened at 2005-01-18 01:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=650116&aid=1104294&group_id=107748 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dario Zilocchi (evew) Assigned to: Nobody/Anonymous (nobody) Summary: Another patch Initial Comment: Added away support, tooltip info on buddies, and changed the server list to authoritative... maybe others fixs too :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=650116&aid=1104294&group_id=107748 |
|
From: Gary K. <gr...@re...> - 2005-01-17 23:06:05
|
On Mon, 2005-01-17 at 22:36 +0000, Zilo wrote: > I realized that the server friends list is limited to 25 people... when =20 > we try to add the 26th buddy an error message rememer us we must remove =20 > someone before :P >=20 > I think 25 people is enough, else we should write a polling procedure =20 > to check our buddies-not-in-fl... >=20 > What do you think? >=20 > Uh! Isn't the time to release something? :) >=20 > cya Adding a limit of adding is fine. But we should not be polling. Just make the server side list authoritive and be done with it. If someone isn't on the server list but is on the local, remove them from the local. As for a release, that's up to don. :) --=20 Gary Kramlich <gr...@re...> |
|
From: Zilo <ko...@gm...> - 2005-01-17 22:30:40
|
I realized that the server friends list is limited to 25 people... when =20 we try to add the 26th buddy an error message rememer us we must remove =20 someone before :P I think 25 people is enough, else we should write a polling procedure =20 to check our buddies-not-in-fl... What do you think? Uh! Isn't the time to release something? :) cya |
|
From: SourceForge.net <no...@so...> - 2005-01-17 01:14:13
|
Patches item #1103607, was opened at 2005-01-17 02:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=650116&aid=1103607&group_id=107748 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dario Zilocchi (evew) Assigned to: Nobody/Anonymous (nobody) Summary: Avoiding to flood battle.net server Initial Comment: I wrote an out queue, instead of write all directly, to prevent flood disconnections by server. Policy variables are BNET_FLOOD_CHARPERSEC and BNET_FLOOD_MAX... I set them in a way that seems work... but I haven't idea of server settings :P Some others small fixs... bnet_conn_close() now free its memory better. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=650116&aid=1103607&group_id=107748 |
|
From: Zilo <ko...@gm...> - 2005-01-14 18:05:54
|
On 01/14/05 16:39:45, Don Seiler wrote:
> Along these same lines, buddy.c has this function:
>=20
> static gboolean
> bnet_nicks_equal(const gchar *nick1, const gchar *nick2) {
> return (gaim_utf8_strcasecmp(nick1, nick2) =3D=3D 0);
> }
>=20
> In proto.c I have a similar function, only I use gaim_utf8_collate(),
> based on grim's suggestion. I also call gaim_utf8_validate() on each
> nick before hand. I suggest changing this function to do that, as
> well as exposing it so I can call it from proto.c for seeing if we =20
> sent the emotes.
Well for nicks in hash, keys are all normalized using gaim_normalize(), =20
I don't think we need an extra-check...
Anyway it's a good idea to have a public function to check nicks.
cya
|
|
From: Gary K. <gr...@re...> - 2005-01-14 16:39:50
|
On Fri, 2005-01-14 at 11:45 +0000, Zilo wrote: > I was thinking about compiling this code on windows platform too... but =20 > I spent all my time without doing nothing... >=20 > I tried to use mingw... but after trying to hack the whole world, I =20 > simply failed :) >=20 > Maybe we can try to use cygwin? > Anyone with experience with *something* on windows? >=20 > cya It's possible, but we'd need to write makefiles for all of it. Theres other plugins I've written that compile one windows using Makefile.mingw's.. --=20 Gary Kramlich <gr...@re...> |
|
From: Don S. <do...@se...> - 2005-01-14 15:39:53
|
Along these same lines, buddy.c has this function:
static gboolean
bnet_nicks_equal(const gchar *nick1, const gchar *nick2) {
return (gaim_utf8_strcasecmp(nick1, nick2) =3D=3D 0);
}
In proto.c I have a similar function, only I use gaim_utf8_collate(),
based on grim's suggestion. I also call gaim_utf8_validate() on each
nick before hand. I suggest changing this function to do that, as well
as exposing it so I can call it from proto.c for seeing if we sent the
emotes.
Let me know what you think.
Don.
--=20
Don Seiler
do...@se...
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xFC87F041
Fingerprint: 0B56 50D5 E91E 4D4C 83B7 207C 76AC 5DA2 FC87 F041
|
|
From: Don S. <do...@se...> - 2005-01-14 14:49:55
|
On 11:45 Fri 14 Jan , Zilo wrote: > Anyone with experience with *something* on windows? I'm sure once we're done, Daniel 'datallah' Atallah will have no problem setting us up for windows building. So don't worry about it at all. Don. --=20 Don Seiler do...@se... Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xFC87F041 Fingerprint: 0B56 50D5 E91E 4D4C 83B7 207C 76AC 5DA2 FC87 F041 |
|
From: Zilo <ko...@gm...> - 2005-01-14 11:38:51
|
I was thinking about compiling this code on windows platform too... but =20 I spent all my time without doing nothing... I tried to use mingw... but after trying to hack the whole world, I =20 simply failed :) Maybe we can try to use cygwin? Anyone with experience with *something* on windows? cya |
|
From: Zilo <ko...@gm...> - 2005-01-13 14:45:18
|
On 01/13/05 14:17:27, Gary Kramlich wrote: > As per the documentation at > http://developer.gnome.org/doc/API/2.0/glib/glib-Unicode-Manipulation.htm= l#g-utf8-normalize >=20 > Converts a string into canonical form, standardizing such issues as > whether a character with an accent is represented as a base character > and combining accent or as a single precomposed character. You should > generally call g_utf8_normalize() before comparing two Unicode > strings. >=20 > So basically, what I tried to do, but it obviously isn't working, is > to store a comparable string in our hash table, so we can test it =20 > before adding a new one, and therefore avoid duplicates. Well, I think that lowering case should be enough, anyway I posted a =20 fix to use gaim_normalize() too :P cya |
|
From: Gary K. <gr...@re...> - 2005-01-13 13:16:11
|
On Thu, 2005-01-13 at 13:16 +0000, Zilo wrote: > On 01/13/05 13:50:51, Gary Kramlich wrote: > > On Thu, 2005-01-13 at 12:21 +0000, evew wrote: > > > I found a bug inside bnet_buddy_add() in a wrong use of > > gaim_normalize > > > (): > > > > > > name =3D gaim_normalize(conn->account, buddy->name); > > > > > > Using name for saving our buddy inside the hash table is wrong > > 'cause > > > gaim_normalize() returns a pointer to a own static array... then =20 > > its > >=20 > > > value isn't the same during time :P > > > > > > As a result of this when receiving friends list all buddy are > > > considered new (because not found in conn->buddies) then (re)added > > in > > > the gaim list... resulting in a big increasing of our popolarity in > > a > > > few seconds :) > > > > > > Anyway, I was thinking about the needing of this line... 'cause if > > it's > > > useful, then we can simply g_strdup() name, but we are already =20 > > using > >=20 > > > gaim_utf8_strcasecmp() to compare nicks in the hash table... isn't > > > enough? > > > > > > cya > >=20 > > I thought we were strcmp'n it which would make that legit.. But if > > we're just comparing pointers, than yeah thats going to be a =20 > > problem... >=20 > Uhm... I'm not sure I understand your answer... excuse my english, just =20 > in case :P >=20 > Anyway, we were strcmp'n it... the problem is that the pointer returned =20 > by gaim_normalize() is always the same, and its contents change every =20 > time we call the function. >=20 > I'm not very familiar with gaim code, so I was asking what is the =20 > meaning of using gaim_normalize()... because if we need it only to > strdown our names, well, there's already gaim_utf8_strcasecmp()... >=20 > Well, in others words, I don't know what g_utf8_normalize() is supposed =20 > to do :) >=20 > cya As per the documentation at http://developer.gnome.org/doc/API/2.0/glib/glib-Unicode-Manipulation.html#= g-utf8-normalize Converts a string into canonical form, standardizing such issues as whether a character with an accent is represented as a base character and combining accent or as a single precomposed character. You should generally call g_utf8_normalize() before comparing two Unicode strings. So basically, what I tried to do, but it obviously isn't working, is to store a comparable string in our hash table, so we can test it before adding a new one, and therefore avoid duplicates. --=20 Gary Kramlich <gr...@re...> |
|
From: Zilo <ko...@gm...> - 2005-01-13 13:10:36
|
On 01/13/05 13:50:51, Gary Kramlich wrote: > On Thu, 2005-01-13 at 12:21 +0000, evew wrote: > > I found a bug inside bnet_buddy_add() in a wrong use of > gaim_normalize > > (): > > > > name =3D gaim_normalize(conn->account, buddy->name); > > > > Using name for saving our buddy inside the hash table is wrong > 'cause > > gaim_normalize() returns a pointer to a own static array... then =20 > its >=20 > > value isn't the same during time :P > > > > As a result of this when receiving friends list all buddy are > > considered new (because not found in conn->buddies) then (re)added > in > > the gaim list... resulting in a big increasing of our popolarity in > a > > few seconds :) > > > > Anyway, I was thinking about the needing of this line... 'cause if > it's > > useful, then we can simply g_strdup() name, but we are already =20 > using >=20 > > gaim_utf8_strcasecmp() to compare nicks in the hash table... isn't > > enough? > > > > cya >=20 > I thought we were strcmp'n it which would make that legit.. But if > we're just comparing pointers, than yeah thats going to be a =20 > problem... Uhm... I'm not sure I understand your answer... excuse my english, just =20 in case :P Anyway, we were strcmp'n it... the problem is that the pointer returned =20 by gaim_normalize() is always the same, and its contents change every =20 time we call the function. I'm not very familiar with gaim code, so I was asking what is the =20 meaning of using gaim_normalize()... because if we need it only to strdown our names, well, there's already gaim_utf8_strcasecmp()... Well, in others words, I don't know what g_utf8_normalize() is supposed =20 to do :) cya |
|
From: Gary K. <gr...@re...> - 2005-01-13 12:49:24
|
On Thu, 2005-01-13 at 12:21 +0000, evew wrote: > I found a bug inside bnet_buddy_add() in a wrong use of gaim_normalize=20 > (): >=20 > name =3D gaim_normalize(conn->account, buddy->name); >=20 > Using name for saving our buddy inside the hash table is wrong 'cause =20 > gaim_normalize() returns a pointer to a own static array... then its =20 > value isn't the same during time :P >=20 > As a result of this when receiving friends list all buddy are =20 > considered new (because not found in conn->buddies) then (re)added in =20 > the gaim list... resulting in a big increasing of our popolarity in a =20 > few seconds :) >=20 > Anyway, I was thinking about the needing of this line... 'cause if it's =20 > useful, then we can simply g_strdup() name, but we are already using =20 > gaim_utf8_strcasecmp() to compare nicks in the hash table... isn't =20 > enough? >=20 > cya I thought we were strcmp'n it which would make that legit.. But if we're just comparing pointers, than yeah thats going to be a problem... --=20 Gary Kramlich <gr...@re...> |
|
From: evew <ko...@gm...> - 2005-01-13 12:15:13
|
I found a bug inside bnet_buddy_add() in a wrong use of gaim_normalize=20 (): name =3D gaim_normalize(conn->account, buddy->name); Using name for saving our buddy inside the hash table is wrong 'cause =20 gaim_normalize() returns a pointer to a own static array... then its =20 value isn't the same during time :P As a result of this when receiving friends list all buddy are =20 considered new (because not found in conn->buddies) then (re)added in =20 the gaim list... resulting in a big increasing of our popolarity in a =20 few seconds :) Anyway, I was thinking about the needing of this line... 'cause if it's =20 useful, then we can simply g_strdup() name, but we are already using =20 gaim_utf8_strcasecmp() to compare nicks in the hash table... isn't =20 enough? cya |
|
From: Gary K. <gr...@re...> - 2005-01-13 08:44:36
|
Well i figured out the issues that I was having.. I'm using the history plugin and it seems that our text that is getting logged isn't valid utf8.. So we're going to have to come up with a way for this to work.. --=20 Gary Kramlich <gr...@re...> |
|
From: Gary K. <gr...@re...> - 2005-01-12 22:18:27
|
On Wed, 2005-01-12 at 20:57 +0000, evew wrote: > On 01/12/05 19:38:26, evew wrote: > >=20 > > I have a question related to gaim: where we must put the code to add =20 > > a buddy to our server friend list, when of course adding a buddy? > >=20 > > There's the bnet_buddy_add() function, but it's called also at =20 > > startup when the buddy already is in fl (even if trying to add the =20 > > buddy twice doesn't hurt... it simply show an error message). > >=20 > > There's a way to catch only the add _new_ buddy event? >=20 > Well I think I resolved the problem in a safe way... now adding/=20 > removing buddies will modify our friends list, updating it... >=20 > I can post diff but you didn't yet commit my last patch so those whould =20 > be merged... any problems with it? >=20 > cya Merging them is fine.. I was going to look at your patch last night and just ran out of time.. but i have tonight completely open.. So the sooner you can submit it.. the better :) --=20 Gary Kramlich <gr...@re...> |
|
From: evew <ko...@gm...> - 2005-01-12 20:51:22
|
On 01/12/05 19:38:26, evew wrote: >=20 > I have a question related to gaim: where we must put the code to add =20 > a buddy to our server friend list, when of course adding a buddy? >=20 > There's the bnet_buddy_add() function, but it's called also at =20 > startup when the buddy already is in fl (even if trying to add the =20 > buddy twice doesn't hurt... it simply show an error message). >=20 > There's a way to catch only the add _new_ buddy event? Well I think I resolved the problem in a safe way... now adding/=20 removing buddies will modify our friends list, updating it... I can post diff but you didn't yet commit my last patch so those whould =20 be merged... any problems with it? cya |
|
From: evew <ko...@gm...> - 2005-01-12 18:32:59
|
I have a question related to gaim: where we must put the code to add a =20 buddy to our server friend list, when of course adding a buddy? There's the bnet_buddy_add() function, but it's called also at startup =20 when the buddy already is in fl (even if trying to add the buddy twice =20 doesn't hurt... it simply show an error message). There's a way to catch only the add _new_ buddy event? cya |
|
From: evew <ko...@gm...> - 2005-01-11 21:31:03
|
On 01/11/05 21:49:24, Don Seiler wrote: > On Tue, January 11, 2005 2:43 pm, evew said: > > $ cvs diff -up > > Cannot access /cvsroot/gaim-bnet/CVSROOT > > No such file or directory >=20 > Sounds like a problem with sourceforge today. Should be fixed later > today. Well I resolved using the ssh protocol... I uploaded then the two new =20 pieces of code :) cya |
|
From: SourceForge.net <no...@so...> - 2005-01-11 21:25:47
|
Patches item #1100453, was opened at 2005-01-11 22:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=650116&aid=1100453&group_id=107748 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dario Zilocchi (evew) Assigned to: Nobody/Anonymous (nobody) Summary: Channel Window Problem Initial Comment: A small fix to the channel window: cause on bnet we can't part from the channel we are on, if we close the chan window then try to reopen it, we wont receive again users list, cause we still are in the chan... this fix the problem, popolating the window with out own list :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=650116&aid=1100453&group_id=107748 |
