Thread: [CSCMail-Users] re: Billienum bug
Brought to you by:
countzer0
Menu
▾
▴
cscmail-users
|
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
|
Thanks for helping keep SourceForge clean.
X