One "interesting" glitch brought to my attention by Sebastian is that a case-insensitive Name Pattern search (the default), when turned into a Complex Search, loses that case-insensitivity. That's not a nice thing to do to someone. I'd go so far as to call it a bad feature.
If two queries happen at the same time, then the returns might come out with apparent garbage. Repeating the query will almost certainly result in clean results.
1050911 22:07:03(9929)< l 25 1050911 22:07:03(9929)< e1i 1 rhys of raven 1050911 22:07:04(9932)< l 25 1050911 22:07:04(9932)< e1i 1 Rhys of Ravenhill 1050911 22:07:05(9929)< EOF 1050911 22:07:06(9932)< EOF
Both these queries returned garbled results.
Istvan: sounds like a simple semaphore around the search might fix this, no? Perl provides for semop, semget, and semctl.
Morsulus: better yet! I simply closed the file handle for the database file after it had been read in and reopen it in the forked process when it needs to pull stuff from the file.
Feature request: I would like glossary links to be turned off by default in armory results. The contrast between blue underlined and black non-underlined distracts and hinders me while I'm scanning blazons for conflicts. I think that almost all the people who are getting the results either already know the meaning of "argent", "embattled", "chevron", etc., or they know so little that the definition will do them little good.
Morsulus has no problem with doing this...
...and in fact found it to be a simple fix to common.pl.
I want to add "by score and blazon" as an option to the sort menu for a complex search (and maybe make it default).
It involves writing a sort routine to do the two-level sort in common.pl and adding the option and processing of it to the cgi
I have it running on my laptop...
I tried doing a Complex Search Form. I just have primary charges, and there are an inordinate number of "and a bordure", "on a bordure", "and a chief", and "on a chief" (presumably people doing the SCA standard "slap on a peripheral to clear a conflict"). So I put in rows for BORDURE and CHIEF and gave each a weight of -10.
You specified an invalid weight (-10) for criterion #3; a weight must be a positive number. You specified an invalid weight (-10) for criterion #4; a weight must be a positive number.
I grumbled and then decided to "comment out" the two rows by using weights of 0. I looked at the error message again, "positive number", sighed, and went thru the three boxes on the two rows to carefully delete text and select [ ] on the drop-down. ... except that, testing it now, I see that it does silently accept a weight of 0.
I don't see an algorithmic reason to prohibit negative weights. Is it really utterly senseless for some reason that I don't see? If not, I suggest allowing it.
I like allowing a weight of 0 to comment out just one row (more convenient than deleting the text of the pattern). So I'd like arbitrary integer weights (the message goes away entirely). Or if, as today, only 0 and positive weights will be allowed, then the error message ("positive") should match the behavior ("non-negative") -- Daniel de Lincoln
Herveus: I'll look at allowing negative weights, with the idea that any item that comes up with a non-positive score falls on the floor (as one might reasonably expect). I'll also look at the input validation to be less of a pain in the butt...I agree with the kvetch.
As of 3PM on Sunday, Nov. 26, 2006, the online Ordinary at sca.org is rejecting the category "Flower - Few petals" as not being a valid description. This problem does not occur with the mirror sites at uwaterloo and farreaches, which are not yet using the most recent update of the database. Possibly these facts are connected.