Menu
▾
▴
ayttm-devel — devlopers list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(264) |
May
(184) |
Jun
(34) |
Jul
(41) |
Aug
(13) |
Sep
(47) |
Oct
(48) |
Nov
(19) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(37) |
Feb
(6) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(21) |
Feb
(28) |
Mar
(15) |
Apr
(56) |
May
(11) |
Jun
(6) |
Jul
(22) |
Aug
(41) |
Sep
|
Oct
(30) |
Nov
(6) |
Dec
(8) |
| 2008 |
Jan
|
Feb
(1) |
Mar
(5) |
Apr
|
May
(4) |
Jun
(35) |
Jul
(21) |
Aug
(22) |
Sep
|
Oct
(21) |
Nov
(36) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
(7) |
Apr
(3) |
May
(10) |
Jun
(1) |
Jul
(20) |
Aug
(29) |
Sep
(21) |
Oct
(14) |
Nov
(23) |
Dec
(5) |
| 2010 |
Jan
|
Feb
(6) |
Mar
(2) |
Apr
(16) |
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(2) |
|
From: Andy <ma...@2w...> - 2003-04-04 00:05:37
|
On Wednesday 02 April 2003 18:41, Philip S Tellis wrote: > i've posted a bug containing a valgrind report on memory leaks. whoeve= r > wants to fix it can have a look. Well, after spending some time looking at leaks [mainly in chat_room and=20 chat_window], I think trying to track them down is going to be a waste of= =20 effort. We can plug as many as we want, but because of the way things ar= e=20 designed, we're always going to introduce more. In my opinion, we need to put the time into serious redesign of the data=20 structures. Memory is allocated and deallocate _everywhere_ by whoever f= eels=20 like doing it - it's impossible to tell whose responsibility it is to=20 allocate/deallocate the memory. Andy |
|
From: Colin L. <co...@co...> - 2003-04-03 21:47:34
|
On 03 Apr 2003 at 15h33, Edward L. Haletky wrote: Hi, > > Never happened on EB like that. > AYTTM is a clone of EB > AYTTM changed code > Bug happens... > > So not sure where it is but I bet it is in the AYTTM code somewhere.... > I have more debug and I run with efence enabled all the time now. I didn't said it wasn't a bug in our code, i said it could come from anywhere, not specially jabber :) -- Colin By filing this bugreport, you challenged my family's honor. Prepare to die! |
|
From: Colin L. <co...@co...> - 2003-04-03 21:26:28
|
On 03 Apr 2003 at 23h15, Andy wrote: Hi, > > I'm interested too :) > > [maloney@finn ayttm]$ find . -type f -a \( -iname "*.h" -o -iname "*.c" > \) -print | xargs grep Recieved > ./modules/aim-oscar/libfaim/aim_rxhandlers.c: faimdprintf(1, > "\nRecieved unknown packet:"); > ./modules/aim-toc/libtoc/libtoc.c: fprintf(stderr,"AIMRecieved > flap: %s\n", buff); > ./modules/icq-toc/libtoc/libtoc.c: fprintf(stderr,"Recieved flap: > %s\n", buff); Thanks, i was feeling lazy :-) Well... Who cares typos on stderr ? (OT: you're really courageous - i'd have done a simple "grep -ir recieved|grep -v ^Binary" ;-) ) -- Colin "This is your life, and it's ending one minute at a time." |
|
From: Edward L. H. <el...@as...> - 2003-04-03 21:25:27
|
Hi Colin, Well here is my thought: Never happened on EB like that. AYTTM is a clone of EB AYTTM changed code Bug happens... So not sure where it is but I bet it is in the AYTTM code somewhere.... I have more debug and I run with efence enabled all the time now. -Edward On Thu, 2003-04-03 at 15:17, Colin Leroy wrote: > On 03 Apr 2003 at 15h17, Edward L. Haletky wrote: > > Hi, > > > We have the tracebacks..... Last one died inside gdk_io_somesuch when > > the system was doing nothing. The traceback showed gdk to gtk_something > > to gtk_main.... Not incredibly helpful. Waiting for it to fail once > > more. Someone did post this traceback in the older > > oh, this one... > > > I personally think its the jabber issue, looking at that as well. > > i don't know. I stupidly closed the bugtracker at savannah, but i remember > this backtrace contained calls to gtk_* and gdk_* from gtk_main(). Not a > single gdb frame was pointing at one of our files, so it could come from > anywhere imho |
|
From: Colin L. <co...@co...> - 2003-04-03 21:18:23
|
On 03 Apr 2003 at 15h17, Edward L. Haletky wrote:
Hi,
> We have the tracebacks..... Last one died inside gdk_io_somesuch when
> the system was doing nothing. The traceback showed gdk to gtk_something
> to gtk_main.... Not incredibly helpful. Waiting for it to fail once
> more. Someone did post this traceback in the older
oh, this one...
> I personally think its the jabber issue, looking at that as well.
i don't know. I stupidly closed the bugtracker at savannah, but i remember
this backtrace contained calls to gtk_* and gdk_* from gtk_main(). Not a
single gdb frame was pointing at one of our files, so it could come from
anywhere imho
--
Colin
panic("Oh boy, that early out of memory?");
2.2.19 linux/arch/mips/mm/init.c
|
|
From: Andy <ma...@2w...> - 2003-04-03 21:17:00
|
On Thursday 03 April 2003 20:06, Colin Leroy wrote: > On 03 Apr 2003 at 12h36, Ben Reser wrote: > > Hi, > > > > First, the nit: 'Received' is not 'Recieved'. > > > > Where did you see the typo? > > I'm interested too :) [maloney@finn ayttm]$ find . -type f -a \( -iname "*.h" -o -iname "*.c" \= )=20 -print | xargs grep Recieved =2E/modules/aim-oscar/libfaim/aim_rxhandlers.c: faimdprintf(1, "\nReciev= ed=20 unknown packet:"); =2E/modules/aim-toc/libtoc/libtoc.c: fprintf(stderr,"AIMRecieved fla= p:=20 %s\n", buff); =2E/modules/icq-toc/libtoc/libtoc.c: fprintf(stderr,"Recieved flap: = %s\n",=20 buff); Andy |
|
From: Edward L. H. <el...@as...> - 2003-04-03 21:09:26
|
Hi, We have the tracebacks..... Last one died inside gdk_io_somesuch when the system was doing nothing. The traceback showed gdk to gtk_something to gtk_main.... Not incredibly helpful. Waiting for it to fail once more. Someone did post this traceback in the older I personally think its the jabber issue, looking at that as well. -Edward On Thu, 2003-04-03 at 15:01, Colin Leroy wrote: > On 03 Apr 2003 at 15h02, Edward L. Haletky wrote: > > Hi, > > > > > One of the key things about AYTTM is stability, unfortunately the > > instability in the client causes the thing to die often. One time last > > night it died with a mmap can not allocate memory error and every now > > and then it will die in a gdk_io routine or even in Jabber. > > > > The valgrind report does not show enough. Perhaps we need to verify that > > all protocols are safe to use. > > When ayttm crashes one has to get a _gdb_ backtrace, and either fix it or > report it... > No wonder segfaults stay there if noone tells about them. |
|
From: Colin L. <co...@co...> - 2003-04-03 21:03:37
|
On 03 Apr 2003 at 22h40, Andy wrote:
Hi,
>
> OK - it's checked in. Please note that because the dependencies don't
> seem to work,
Yep, they don't with automake 1.6 and 1.7. Philip has no problems, he uses
1.4 if i remember correctly.
Maybe we should have a look at our Makefiles :)
> you should make clean && make.
I always do so when i see a commit across /src and /modules :)
--
Colin
panic("Oh boy, that early out of memory?");
2.2.19 linux/arch/mips/mm/init.c
|
|
From: Colin L. <co...@co...> - 2003-04-03 21:01:53
|
On 03 Apr 2003 at 15h02, Edward L. Haletky wrote:
Hi,
>
> One of the key things about AYTTM is stability, unfortunately the
> instability in the client causes the thing to die often. One time last
> night it died with a mmap can not allocate memory error and every now
> and then it will die in a gdk_io routine or even in Jabber.
>
> The valgrind report does not show enough. Perhaps we need to verify that
> all protocols are safe to use.
When ayttm crashes one has to get a _gdb_ backtrace, and either fix it or
report it...
No wonder segfaults stay there if noone tells about them.
--
Colin
panic("Oh boy, that early out of memory?");
2.2.19 linux/arch/mips/mm/init.c
|
|
From: Edward L. H. <el...@as...> - 2003-04-03 20:53:38
|
Hi Guys, One of the key things about AYTTM is stability, unfortunately the instability in the client causes the thing to die often. One time last night it died with a mmap can not allocate memory error and every now and then it will die in a gdk_io routine or even in Jabber. The valgrind report does not show enough. Perhaps we need to verify that all protocols are safe to use. I think this bug needs to be fixed and we all have to chip in to help fix it. I suggest we drop everything else until it is fixed.... The valgrind report while useful has too many blanks that look like they come from modules. Perhaps we can attempt other types of checking? Thoughts, Edward |
|
From: Andy <ma...@2w...> - 2003-04-03 20:42:09
|
OK - it's checked in. Please note that because the dependencies don't se= em to=20 work, you should make clean && make. Andy |
|
From: Philip S T. <phi...@gm...> - 2003-04-03 20:10:49
|
Sometime on Apr 3, Edward L. Haletky assembled some asciibets to say: > Command line options are really a bad idea for Windows. I suggest we > make it a selectable option or force it to always no autoresize or just > keep it a hidden variable. Its not as if it is broken. This is not about the autoresize. It's about advanced prefs like rescan modules directory and having multiple modules directories. Philip |
|
From: Edward L. H. <el...@as...> - 2003-04-03 20:01:37
|
Hi, Command line options are really a bad idea for Windows. I suggest we make it a selectable option or force it to always no autoresize or just keep it a hidden variable. Its not as if it is broken. -Edward On Thu, 2003-04-03 at 13:01, Colin Leroy wrote: > On 04 Apr 2003 at 00h22, Philip S Tellis wrote: > > Hi, > > > > One of the most geeky options, moved to general ? No, i don't agree! > > > why would we want that? > > > > I think we should have an advanced options part, that is enabled or > > disabled by a hidden pref. That way geeks can get geeky prefs. > > It's better, yes, but a hidden pref is perhaps not the best way to > enable/disable it - maybe a command-line parameter is better for this. |
|
From: Philip S T. <phi...@gm...> - 2003-04-03 19:19:16
|
ok, the file should be attached to the bug now. Philip |
|
From: Philip S T. <phi...@gm...> - 2003-04-03 19:07:31
|
Sometime on Apr 3, Edward L. Haletky assembled some asciibets to say: > Please keep do_noautoresixe, well not in the code as its hidden, but > keep it in the hidden stuff, its very important that the window not > always grow. So why not just make it default? Never let it grow. Force it to true for everyone. Philip |
|
From: Colin L. <co...@co...> - 2003-04-03 19:02:10
|
On 04 Apr 2003 at 00h22, Philip S Tellis wrote: Hi, > > One of the most geeky options, moved to general ? No, i don't agree! > > why would we want that? > > I think we should have an advanced options part, that is enabled or > disabled by a hidden pref. That way geeks can get geeky prefs. It's better, yes, but a hidden pref is perhaps not the best way to enable/disable it - maybe a command-line parameter is better for this. -- Colin Random BOFH excuse: Atilla the Hub |
|
From: Philip S T. <phi...@gm...> - 2003-04-03 18:53:31
|
Sometime on Apr 3, Colin Leroy assembled some asciibets to say: > One of the most geeky options, moved to general ? No, i don't agree! > why would we want that? I think we should have an advanced options part, that is enabled or disabled by a hidden pref. That way geeks can get geeky prefs. Philip |
|
From: Philip S T. <phi...@gm...> - 2003-04-03 18:51:41
|
Sometime on Apr 3, Andy assembled some asciibets to say: > O.K. I'll just wait a bit to see what the other guys have to say. Fine by me. I'll throw in the progress bars soon. |
|
From: Edward L. H. <el...@as...> - 2003-04-03 18:49:38
|
Hello, Please keep do_noautoresixe, well not in the code as its hidden, but keep it in the hidden stuff, its very important that the window not always grow. -Edward On Thu, 2003-04-03 at 15:28, Andy wrote: > [sorry Colin - stupid mailer inserted wrong reply address] > > On Thursday 03 April 2003 17:01, Colin Leroy wrote: > > On 03 Apr 2003 at 19h50, Andy wrote: > [snip] > > > So what's different? Well, everything should be functionally the same > > > except: > > > 1) You cannot set the modules path in the pref window > > > > You mean it's now hidden, i suppose.. > > Yeah, in fact that brings up a point - in the new prefs.c's > ayttm_prefs_init(), I initialize all the prefs that were initialized in the > old prefs_window.c. We should look at the 'hidden' ones and get rid of > useless ones [i.e. do_noautoresize]. > > [snip] > > > In stage two, I plan to completely redesign the prefs window. I will > > > continue to do this on another branch until it's in a reasonable state > > > at which point I will ask you to take a look at it. > > > > ok, no problem! > > > > > I have tried to merge in all the changes to prefs.[ch] and > > > prefs_window.[ch] that apply, so if you have made changes to them in the > > > last couple of weeks, please take a look. > > > > > > That's about it. I will wait for discussion and merge it in later > > > tonight! > > > > It seems quite fine to me... Merge whenever you feel like! > > O.K. I'll just wait a bit to see what the other guys have to say. > > Andy > > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > Ayttm-devel mailing list > Ayt...@li... > https://lists.sourceforge.net/lists/listinfo/ayttm-devel |
|
From: Colin L. <co...@co...> - 2003-04-03 18:43:05
|
On 03 Apr 2003 at 12h28, Edward L. Haletky wrote: Hi, > > I think the module path should not be hidden but moved to general or > somesuch. One of the most geeky options, moved to general ? No, i don't agree! why would we want that? -- Colin "This is your life, and it's ending one minute at a time." |
|
From: Andy <ma...@2w...> - 2003-04-03 18:30:25
|
[sorry Colin - stupid mailer inserted wrong reply address] On Thursday 03 April 2003 17:01, Colin Leroy wrote: > On 03 Apr 2003 at 19h50, Andy wrote: [snip] > > So what's different? Well, everything should be functionally the same > > except: > > =091) You cannot set the modules path in the pref window > > You mean it's now hidden, i suppose.. Yeah, in fact that brings up a point - in the new prefs.c's=20 ayttm_prefs_init(), I initialize all the prefs that were initialized in t= he=20 old prefs_window.c. We should look at the 'hidden' ones and get rid of=20 useless ones [i.e. do_noautoresize]. [snip] > > In stage two, I plan to completely redesign the prefs window. I will > > continue to do this on another branch until it's in a reasonable stat= e > > at which point I will ask you to take a look at it. > > ok, no problem! > > > I have tried to merge in all the changes to prefs.[ch] and > > prefs_window.[ch] that apply, so if you have made changes to them in = the > > last couple of weeks, please take a look. > > > > That's about it. I will wait for discussion and merge it in later > > tonight! > > It seems quite fine to me... Merge whenever you feel like! O.K. I'll just wait a bit to see what the other guys have to say. Andy |
|
From: Edward L. H. <el...@as...> - 2003-04-03 18:20:01
|
Hi, I think the module path should not be hidden but moved to general or somesuch. My 2 cents, Edward On Thu, 2003-04-03 at 14:50, Andy wrote: > [After waiting an hour and a half for this to show up on the list, I decided > it was MIA and thought I'd try again - sorry if it's a duplicate.] > > Hi guys. Now that 0.2.3 is out, I would like to merge in the first part of my > prefs changes. My goal with the first part was to keep it as functionally > equivalent as possible. In stage two some structs will change and the way > module prefs are handled will be simplified [e.g. no more pointers to module > globals...]. > > So what's different? Well, everything should be functionally the same except: > 1) You cannot set the modules path in the pref window > 2) When changing a module's prefs and click OK, they are not applied until > the user clicks OK on the prefs window. This is to set up for stage two. > 3) All prefs are written out, even if they are set to the default [e.g. > alternate_browser] > > No really, what's different? > 1) The prefs which are settable by the user are copied into a struct and > passed to the prefs window to do whatever it likes to them. They are not > applied unless the prefs window calls the ayttm_prefs_apply() function. > 2) Reading/writing prefs has been separated from applying them, and the prefs > window doesn't know anything about reading or writing our prefs. > 3) We now have one place to set our default prefs [ayttm_prefs_init()]. This > is called early on in main(). [Maybe the correct place to handle ayttmrc > stuff as well?] > 4) The prefs are independent of the prefs window and therefore of GTK. > 5) Probably other things I'm not thinking of at the moment. > > In stage two, I plan to completely redesign the prefs window. I will continue > to do this on another branch until it's in a reasonable state at which point > I will ask you to take a look at it. > > I have tried to merge in all the changes to prefs.[ch] and prefs_window.[ch] > that apply, so if you have made changes to them in the last couple of weeks, > please take a look. > > That's about it. I will wait for discussion and merge it in later tonight! > > Andy > > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > Ayttm-devel mailing list > Ayt...@li... > https://lists.sourceforge.net/lists/listinfo/ayttm-devel |
|
From: Colin L. <co...@co...> - 2003-04-03 18:02:04
|
On 03 Apr 2003 at 19h50, Andy wrote: Hi, > > Hi guys. Now that 0.2.3 is out, I would like to merge in the first part > of my prefs changes. My goal with the first part was to keep it as > functionally equivalent as possible. In stage two some structs will > change and the way module prefs are handled will be simplified [e.g. no > more pointers to module globals...]. > > So what's different? Well, everything should be functionally the same > except: > 1) You cannot set the modules path in the pref window You mean it's now hidden, i suppose.. > 2) When changing a module's prefs and click OK, they are not > applied until > the user clicks OK on the prefs window. This is to set up for stage > two. > 3) All prefs are written out, even if they are set to the default > [e.g. > alternate_browser] > > No really, what's different? > 1) The prefs which are settable by the user are copied into a > struct and > passed to the prefs window to do whatever it likes to them. They are > not applied unless the prefs window calls the ayttm_prefs_apply() > function. > 2) Reading/writing prefs has been separated from applying them, > and the prefs > window doesn't know anything about reading or writing our prefs. > 3) We now have one place to set our default prefs > [ayttm_prefs_init()]. This > is called early on in main(). [Maybe the correct place to handle > ayttmrc stuff as well?] > 4) The prefs are independent of the prefs window and therefore of > GTK. 5) Probably other things I'm not thinking of at the moment. > > In stage two, I plan to completely redesign the prefs window. I will > continue to do this on another branch until it's in a reasonable state > at which point I will ask you to take a look at it. ok, no problem! > I have tried to merge in all the changes to prefs.[ch] and > prefs_window.[ch] that apply, so if you have made changes to them in the > last couple of weeks, please take a look. > > That's about it. I will wait for discussion and merge it in later > tonight! It seems quite fine to me... Merge whenever you feel like! Cheers, -- Colin |
|
From: Andy <ma...@2w...> - 2003-04-03 17:51:37
|
[After waiting an hour and a half for this to show up on the list, I deci= ded=20 it was MIA and thought I'd try again - sorry if it's a duplicate.] Hi guys. Now that 0.2.3 is out, I would like to merge in the first part = of my=20 prefs changes. My goal with the first part was to keep it as functionall= y=20 equivalent as possible. In stage two some structs will change and the wa= y=20 module prefs are handled will be simplified [e.g. no more pointers to mod= ule=20 globals...]. So what's different? Well, everything should be functionally the same exc= ept: =091) You cannot set the modules path in the pref window =092) When changing a module's prefs and click OK, they are not applied u= ntil=20 the user clicks OK on the prefs window. This is to set up for stage two. =093) All prefs are written out, even if they are set to the default [e.g= =2E=20 alternate_browser] No really, what's different? =091) The prefs which are settable by the user are copied into a struct a= nd=20 passed to the prefs window to do whatever it likes to them. They are not= =20 applied unless the prefs window calls the ayttm_prefs_apply() function. =092) Reading/writing prefs has been separated from applying them, and th= e prefs=20 window doesn't know anything about reading or writing our prefs. =093) We now have one place to set our default prefs [ayttm_prefs_init()]= =2E This=20 is called early on in main(). [Maybe the correct place to handle ayttmrc= =20 stuff as well?] =094) The prefs are independent of the prefs window and therefore of GTK. =095) Probably other things I'm not thinking of at the moment. In stage two, I plan to completely redesign the prefs window. I will con= tinue=20 to do this on another branch until it's in a reasonable state at which po= int=20 I will ask you to take a look at it. I have tried to merge in all the changes to prefs.[ch] and prefs_window.[= ch]=20 that apply, so if you have made changes to them in the last couple of wee= ks,=20 please take a look. That's about it. I will wait for discussion and merge it in later tonigh= t! Andy |
|
From: Philip S T. <phi...@gm...> - 2003-04-03 13:04:46
|
On Thu, 3 Apr 2003, Colin Leroy wrote: > You appear in the subscribed members for the three lists, with no special > flags - i don't understand how comes :-/ maybe try to re-subscribe... This has started working now. It took two days for the subscription confirmation mail to reach my mail box. Philip -- Each new user of a new system uncovers a new class of bugs. -- Kernighan |
24 messages has been excluded from this view by a project administrator.