Hi Robby,<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">> attached file 'sortmult.diff' loops through all the values, so that,<br>
</blockquote><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote"><div> </div></blockquote><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
I added some unit tests and tweaked your patch just a bit, but just<br>
committed it. You're right about the ordering for empty strings. I'm not<br>
sure why I did it that way, so I did reverse it to be consistent with<br>
strings.<br></blockquote>
<br>Thank you. I'm glad you wrote the unit tests: I looked at the tests you committed but I don't understand how they work. I hope they weren't too much trouble!<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
> order in the group view. The attached file 'sortgroups.diff' is a bit<br><br>I see what you mean. I think your approach works well enough. I'm going to<br>
poke at it a bit more myself, but I'll certainly fix that sorting in the<br>
group view.<br></blockquote>
<br>Thank you again!<br>I saw that you've already committed the changes; I was glad to see that you found a good way to re-use the field type checking.<br>
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">There are quite a lot of compiler warnings for some of the old internal c<br></blockquote>
<blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
libraries I use, like btparse and pilotdb. Occasionally I think about fixing<br>
them up, but since they're old and crusty anyways, it's not worth the effort.<br></blockquote>
<br>Makes perfect sense.<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
use it. I develop on 64-bit opensuse, so I don't know if there's anything<br></blockquote><br>Neat, that's what I run at work :)<br><br>Andrew<br><br clear="all">---<br>Drew Bennett<br><a href="mailto:drewbenn@gmail.com">drewbenn@gmail.com</a><br>
<br><br><div class="gmail_quote">On Fri, Dec 3, 2010 at 12:25 PM, Robby Stephenson <span dir="ltr"><<a href="mailto:robby@periapsis.org">robby@periapsis.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Andrew,<br>
<div class="im"><br>
On Sunday 21 November 2010, Andrew Bennett wrote:<br>
> I've noticed two minor issues when sorting numbers. I've created<br>
> patches for both of them, although there are probably better ways of<br>
> fixing them.<br>
<br>
</div>Cool, thanks for taking the time and effort to do so!<br>
<div class="im"><br>
> The first, and less important, is that when a number field has<br>
> multiple values, sorting is only performed on the first value. The<br>
> attached file 'sortmult.diff' loops through all the values, so that,<br>
> for example, "1; 2" will always come before "1; 3". There's not a lot<br>
> to this patch, although one comment in NumberComparison::compare() had<br>
> me a little confused:<br>
> // by default, an empty string would get sorted before "1" because<br>
> toFloat() turns it into "0"<br>
> // I want the empty strings to be at the end<br>
> This is different from how strings get sorted, where empty strings get<br>
> put at the beginning (because it is just a simple string compare); it<br>
> seemed odd that numbers and strings are being treated differently.<br>
<br>
</div>I added some unit tests and tweaked your patch just a bit, but just<br>
committed it. You're right about the ordering for empty strings. I'm not<br>
sure why I did it that way, so I did reverse it to be consistent with<br>
strings.<br>
<div class="im"><br>
> The second, which I'd really like to see make it into Tellico in some<br>
> form, is that numbers are sorted in alphabetic, rather than numeric,<br>
> order in the group view. The attached file 'sortgroups.diff' is a bit<br>
> more complex, and when sorting in the group view it checks the field<br>
> type and calls the field's custom sort function for certain types<br>
> (number, boolean, rating, date, and LCC).<br>
<br>
</div>I see what you mean. I think your approach works well enough. I'm going to<br>
poke at it a bit more myself, but I'll certainly fix that sorting in the<br>
group view.<br>
<div class="im"><br>
> Finally, when I build for the first time, I see a whole lot of<br>
> warnings about deprecated functions. It could be due to my<br>
> environment (Ubuntu 10.10, 64-bit, GNOME), and they didn't seem to<br>
> affect anything. I didn't pay any attention to them, but wanted to<br>
> mention it in case you care (they disappear on subsequent builds, so<br>
> it's pretty easy to forget about them).<br>
<br>
</div>There are quite a lot of compiler warnings for some of the old internal c<br>
libraries I use, like btparse and pilotdb. Occasionally I think about fixing<br>
them up, but since they're old and crusty anyways, it's not worth the effort.<br>
<br>
If there are deprecated warnings for anything else, it'd be worth fixing.<br>
Sometimes, with KDE I think, there will be a warning like that just because<br>
I'm using a header that includes a deprecated declaration even if I never<br>
use it. I develop on 64-bit opensuse, so I don't know if there's anything<br>
different about GNOME on Ubuntu that might show more deprecation warnings,<br>
though.<br>
<br>
Thanks again, and sorry for the late reply!<br>
<font color="#888888">Robby<br>
</font></blockquote></div><br>