Thread: [CSCMail-Users] re: Billienum bug
Brought to you by:
countzer0
From: Muhri <mu...@ya...> - 2002-05-23 08:22:42
|
> Hi Steve, > > I fixed this for Pronto on Sept. 9th when it all > happened. Here is what > you need to do: > > $message_clist->set_compare_func(\&my_sort_func); > > sub my_sort_func > { > my ($clist, $first, $second) = @_; > if ($first =~ /^\d+$/) { > What if we are sorting the subject field and one >node is numeric, and the > other is text? This will attempt to sort that >numerically (incorrect) very rare but yeah - you are right. Should check both. > if ($first > $second) { return -1; } > if ($first == $second) { return 0; } > return 2; > Why not use <=> ? thats what it's for.... because <=> never returns a value greater than 1 - check http://developer.gnome.org/doc/API/gtk/gtkclist.html#GTKCLISTCOMPAREFUNC > } > my @stuff = ($first,$second); > A two element array? why not? > my @sorted = sort {uc($a) cmp uc($b)} @stuff; > Sort our two elements the first time using >cmp... (which compares them...) > if ($sorted[0] eq $first) { return -1; } > compare two elements (why? you just did that...) > if ($first eq $second) { return 0; } > compare two elements (redundant) > return 2; > } > Oh, you just re-implimented cmp!? No, once again check the documentation, i'm following the api docs, you need to return a value greater than 1 sometimes. Yeah, your func below might be a bit nicer but it'll never return a value greater than 2 - btw you dont have to handle sort dir, gtk will pass teh values in the way they are supposed to be sorted - asc or desc. sorry for the very late reply, i changed mail providers at the very same time i sent this email and i just got my email from there ! >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ouch! Try: sub my_sort_func { my ($clist, $a, $b) = @_; # Might as well handle sortdir here (not strictly needed) if ($clist->{'sortdir'} eq "descending") { my $tmp = $a; $a = $b; $b = $tmp; } # Are both nodes numeric? if ($a =~ /^\d+$/ and $b =~ /^\d+$/) { return ($a <=> $b); # nope.... } else { return (uc($a) cmp uc($b)); } } CSCMail users: I will be releasing version 1.7.10 in the next few days that addresses this bug as well encorporating quite a few other code cleanups... In fact, the reason I am not releasing it right this second involves these code cleanups... I was in the middle of re-coding the way Folders are handled internally, as well as getting rid of the "no more than 99 normal folders" restriction (this involves folders with id's equal to or greater than 100 being treated as "virtual" search folders... I am adding a new field to the database that handles the type of folder so there will no longer be any arbitrary limits to the number of folders) I guess I should release a 1.6.x version that fixes this bug as well? Is anyone still using 1.6.x? -CZ __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
From: Count Z. <cou...@cy...> - 2002-05-23 13:48:24
|
That is a typo in the Gtk Documentation. It should read: Returns : 0 if the nodes are equal, less than 0 if the first node should come before the second, and greater than 0 if the second come before the first Not: Returns : 0 if the nodes are equal, less than 0 if the first node should come before the second, and greater than 1 if the second come before the first When in doubt, check the code. -Steve ----- Original Message ----- From: "Muhri" <mu...@ya...> To: <cou...@cy...> Cc: <csc...@so...> Sent: Thursday, May 23, 2002 4:22 AM Subject: [CSCMail-Users] re: Billienum bug > > Hi Steve, > > > > I fixed this for Pronto on Sept. 9th when it all > > happened. Here is what > > you need to do: > > > > $message_clist->set_compare_func(\&my_sort_func); > > > > sub my_sort_func > > { > > my ($clist, $first, $second) = @_; > > if ($first =~ /^\d+$/) { > > > What if we are sorting the subject field and one > >node is numeric, and the > > other is text? This will attempt to sort that > >numerically (incorrect) > > > very rare but yeah - you are right. Should check both. > > > if ($first > $second) { return -1; } > > if ($first == $second) { return 0; } > > return 2; > > > Why not use <=> ? thats what it's for.... > > because <=> never returns a value greater than 1 - > check > http://developer.gnome.org/doc/API/gtk/gtkclist.html#GTKCLISTCOMPAREFUNC > > > } > > my @stuff = ($first,$second); > > > A two element array? > > why not? > > > my @sorted = sort {uc($a) cmp uc($b)} @stuff; > > > Sort our two elements the first time using >cmp... > (which compares them...) > > > if ($sorted[0] eq $first) { return -1; } > > > compare two elements (why? you just did that...) > > > if ($first eq $second) { return 0; } > > > compare two elements (redundant) > > > return 2; > > } > > Oh, you just re-implimented cmp!? > > > No, once again check the documentation, i'm following > the api docs, you need to return a value greater than > 1 sometimes. > > > Yeah, your func below might be a bit nicer but it'll > never return a value greater than 2 - btw you dont > have to handle sort dir, gtk will pass teh values in > the way they are supposed to be sorted - asc or desc. > > sorry for the very late reply, i changed mail > providers at the very same time i sent this email and > i just got my email from there ! > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Ouch! > > Try: > > sub my_sort_func { > my ($clist, $a, $b) = @_; > > # Might as well handle sortdir here (not strictly > needed) > if ($clist->{'sortdir'} eq "descending") { > my $tmp = $a; > $a = $b; > $b = $tmp; > } > > # Are both nodes numeric? > if ($a =~ /^\d+$/ and $b =~ /^\d+$/) { > return ($a <=> $b); > # nope.... > } else { > return (uc($a) cmp uc($b)); > } > } > > > CSCMail users: I will be releasing version 1.7.10 in > the next few days that > addresses this bug as well encorporating quite a few > other code cleanups... > In fact, the reason I am not releasing it right this > second involves these > code cleanups... I was in the middle of re-coding the > way Folders are > handled internally, as well as getting rid of the "no > more than 99 normal > folders" restriction (this involves folders with id's > equal to or greater > than 100 being treated as "virtual" search folders... > I am adding a new > field to the database that handles the type of folder > so there will no > longer be any arbitrary limits to the number of > folders) > > I guess I should release a 1.6.x version that fixes > this bug as well? Is > anyone still using 1.6.x? > > -CZ > > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > | Be sure to read the CSCMail FAQ: > | http://www.cscmail.net/cscmail.faq > | > | CSCMail Home Page: > | http://www.cscmail.net > | > | To unsubscribe or change your preferences: > | https://lists.sourceforge.net/lists/listinfo/cscmail-users > > |
From: Muhri <mu...@ya...> - 2002-05-23 16:23:12
|
Really! weird, you would have thought that they fixed their API it has been stable for the past couple of years. Anyho, its working just fine ;-) Maher --- Count Zero <cou...@cy...> wrote: > That is a typo in the Gtk Documentation. It should > read: > > Returns : 0 if the nodes are equal, less than 0 if > the first node should > come before the second, and greater than 0 if the > second come before the > first > > Not: > > Returns : 0 if the nodes are equal, less than 0 if > the first node should > come before the second, and greater than 1 if the > second come before the > first > > When in doubt, check the code. > > -Steve > > ----- Original Message ----- > From: "Muhri" <mu...@ya...> > To: <cou...@cy...> > Cc: <csc...@so...> > Sent: Thursday, May 23, 2002 4:22 AM > Subject: [CSCMail-Users] re: Billienum bug > > > > > Hi Steve, > > > > > > I fixed this for Pronto on Sept. 9th when it > all > > > happened. Here is what > > > you need to do: > > > > > > > $message_clist->set_compare_func(\&my_sort_func); > > > > > > sub my_sort_func > > > { > > > my ($clist, $first, $second) = @_; > > > if ($first =~ /^\d+$/) { > > > > > What if we are sorting the subject field and one > > >node is numeric, and the > > > other is text? This will attempt to sort that > > >numerically (incorrect) > > > > > > very rare but yeah - you are right. Should check > both. > > > > > if ($first > $second) { return -1; } > > > if ($first == $second) { return 0; } > > > return 2; > > > > > Why not use <=> ? thats what it's for.... > > > > because <=> never returns a value greater than 1 - > > check > > > http://developer.gnome.org/doc/API/gtk/gtkclist.html#GTKCLISTCOMPAREFUNC > > > > > } > > > my @stuff = ($first,$second); > > > > > A two element array? > > > > why not? > > > > > my @sorted = sort {uc($a) cmp uc($b)} @stuff; > > > > > Sort our two elements the first time using > >cmp... > > (which compares them...) > > > > > if ($sorted[0] eq $first) { return -1; } > > > > > compare two elements (why? you just did > that...) > > > > > if ($first eq $second) { return 0; } > > > > > compare two elements (redundant) > > > > > return 2; > > > } > > > Oh, you just re-implimented cmp!? > > > > > > No, once again check the documentation, i'm > following > > the api docs, you need to return a value greater > than > > 1 sometimes. > > > > > > Yeah, your func below might be a bit nicer but > it'll > > never return a value greater than 2 - btw you dont > > have to handle sort dir, gtk will pass teh values > in > > the way they are supposed to be sorted - asc or > desc. > > > > sorry for the very late reply, i changed mail > > providers at the very same time i sent this email > and > > i just got my email from there ! > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Ouch! > > > > Try: > > > > sub my_sort_func { > > my ($clist, $a, $b) = @_; > > > > # Might as well handle sortdir here (not strictly > > needed) > > if ($clist->{'sortdir'} eq "descending") > { > > my $tmp = $a; > > $a = $b; > > $b = $tmp; > > } > > > > # Are both nodes numeric? > > if ($a =~ /^\d+$/ and $b =~ /^\d+$/) { > > return ($a <=> $b); > > # nope.... > > } else { > > return (uc($a) cmp uc($b)); > > } > > } > > > > > > CSCMail users: I will be releasing version 1.7.10 > in > > the next few days that > > addresses this bug as well encorporating quite a > few > > other code cleanups... > > In fact, the reason I am not releasing it right > this > > second involves these > > code cleanups... I was in the middle of re-coding > the > > way Folders are > > handled internally, as well as getting rid of the > "no > > more than 99 normal > > folders" restriction (this involves folders with > id's > > equal to or greater > > than 100 being treated as "virtual" search > folders... > > I am adding a new > > field to the database that handles the type of > folder > > so there will no > > longer be any arbitrary limits to the number of > > folders) > > > > I guess I should release a 1.6.x version that > fixes > > this bug as well? Is > > anyone still using 1.6.x? > > > > -CZ > > > > > > __________________________________________________ > > Do You Yahoo!? > > LAUNCH - Your Yahoo! Music Experience > > http://launch.yahoo.com > > > > > _______________________________________________________________ > > > > Don't miss the 2002 Sprint PCS Application > Developer's Conference > > August 25-28 in Las Vegas -- > http://devcon.sprintpcs.com/adp/index.cfm > > > > _______________________________________________ > > | Be sure to read the CSCMail FAQ: > > | http://www.cscmail.net/cscmail.faq > > | > > | CSCMail Home Page: > > | http://www.cscmail.net > > | > > | To unsubscribe or change your preferences: > > | > https://lists.sourceforge.net/lists/listinfo/cscmail-users > > > > > > > > === message truncated === __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |