Actually, it's still broken. The gratuitous repetition of the disambiguation suffix after the access date's year is gone now, but the sorting still fails to be chronological in Forum Posts. Here's a few usenet articles by the same author:
(1993p, December 8) (1993q, April 8) (1993r, December 18) (1993s, February 27)
Forum Posts have Zotero item type forumPost, which maps to CSL item type webpage. In the style, those should be receiving the full date as the sort key as far as I can tell. I'll need sample data in order to check further.
Ouch! It turned out that I'd switched the offending document to APA 5th edition at some point while trying to find an author-date style that works. Switching it back to APA 6th edition solved the problem.
That certainly looks useful. Could you do the feedback gadget thing again? If the reference has already been saved once, all of the data should come through when you submit to the queue. (If an item is missing I may come back with a second request.)
What might be going on here is failure to update the suffixes. In building this data set, were the strange suffixes ever valid for the relevant items at any point? Or did it just suddenly start apply incorrect suffixes willy-nilly?
(Edit: when you submit, send in the last reference in the series; that should pull in the data for all of the preceding items.)
Note that the year disambiguation in the cited example isn't "willy nilly" -- with a few bumps along the way, it just starts year-disambiguating with the first item and then keeps incrementing on and on without ever resetting to "a" for a new year.
Sometimes I can hit "Refresh" and get a perfectly normal rendering:
Smith, J. (1989, December 8). Smith, J. (1990, May 10). Smith, J. (1991a, February 26). Smith, J. (1991b, June 14). Smith, J. (1991c, August 30). Smith, J. (1991d, October 1). Smith, J. (1991e, December 25). Smith, J. (1992, September 21). Smith, J. (1993a). Smith, J. (1993b, January 8). Smith, J. (1993c, January 12). Smith, J. (1993d, January 13). Smith, J. (1993e, January 16). Smith, J. (1993f, January 18). Smith, J. (1993g, January 29).
[etc.]
It's soul-crushingly slow, however: The article has some 230 references, and refreshing them on a T61 Thinkpad takes five minutes during which Firefox and LibreOffice freeze up: at first it's Firefox that keeps hogging 100% of CPU for two minutes, then there's another three minutes during which CPU usage is way down but LibreOffice is frozen anyway, then eventually the process is done and the references are re-sorted fine.
I'm assuming the "feedback gadget thing" is the "Report Error..." feature under the cogwheel icon? After doing the Refresh reported above, there's nothing there: "Report Error..." is greyed out.
@anark: I'm sorry, mistook you for another correspondent. The feedback gadget is a separate plugin. Don't worry about it; it sounds like it's not the tool for the job.
I saw something similar recently during development work on the processor -- changes in rendering with repeated refreshes. The symptoms I saw have been fixed in the latest version. There have been some other small fixes as well, and you may seem an improvement in stability in the next Zotero release. The fixes won't help with your performance issues though. You might try switching to a style that is less heavily reliant on disambiguation while drafting -- one of the Chicago note styles might be a good candidate -- and switch to the production style for the final rendering.
Actually, it seems to be worse. Output of this type (gratuitous run-on disambiguation increments) seems to be the norm in APA v.6 now:
Smith, J. (1993a, February 2). Smith, J. (1995b, February 20). Smith, J. (1995c, February 25). Smith, J. (1995d, March 28). Smith, J. (1995e, July 19). Smith, J. (1995f, August 3). Smith, J. (1996g, January 29). Smith, J. (1996h, February 11). Smith, J. (1996i, February 14). Smith, J. (1996j, February 20). Smith, J. (1996k, April 24). Smith, J. (1997l, August 19). Smith, J. (1997m, August 20). Smith, J. (1997n, December 12). Smith, J. (1997o, December 19). Smith, J. (1998p, February 13). Smith, J. (1998q, February 23). Smith, J. (1999r, December).
I need to hit Refresh to get the correct output:
Smith, J. (1993, February 2). Smith, J. (1995a, February 20). Smith, J. (1995b, February 25). Smith, J. (1995c, March 28). Smith, J. (1995d, July 19). Smith, J. (1995e, August 3). Smith, J. (1996a, January 29). Smith, J. (1996b, February 11). Smith, J. (1996c, February 14). Smith, J. (1996d, February 20). Smith, J. (1996e, April 24). Smith, J. (1997a, August 19). Smith, J. (1997b, August 20). Smith, J. (1997c, December 12). Smith, J. (1997d, December 19). Smith, J. (1998a, February 13). Smith, J. (1998b, February 23). Smith, J. (1999, December).
I can't hit Refresh right after getting the bad output, however, as this will give me an error. I need to shut everything down and restart the X server (closing and re-opening the document still results in the error. Closing and re-starting LibreOffice and then re-opening the document still results in the error).
I need to be able to reproduce this locally in order to work on it. Can you provide a description of the steps I should go through to trigger the failure?
Brooker, C. (2009a, January 5). Brooker, C. (2009b, August 22). Brooker, C. (2010, February 1). Brooker, C. (2011c, July 24). Brooker, C. (2011d, July 31).
While creating the sample, I saved, closed and re-opened the document after two or three citations, and then hit Refresh, which may or may not have had an effect on the final outcome.
Just to complete the procedure: I hit Refresh on the faulty output above, causing the document to crash with the error:
this.state.registry.registry[mylds[i]] is undefined.
I reset the X server, started LibreOffice, waited for LibreOffice to recover the crashed document, hit Refresh once the document had loaded, and, hey -- perfect output:
Brooker, C. (2009a, January 5). Brooker, C. (2009b, August 22). Brooker, C. (2010, February 1). Brooker, C. (2011a, July 24). Brooker, C. (2011b, July 31).
Software versions, for what it may be worth: Zotero 2.1.10, Firefox 7.0.1, LibreOffice 3.3.4, Ubuntu 11.4
no - at least as far as the beta is concerned I'd expect that to happen sooner rather than later. I think there's a good chance that there won't be any future 2.1 releases, though.
So my best bet for getting correct APA author-date citations over the next few months is to monitor the Zotero blog and wait for the announcement of a beta release?
it depends - there are currently two Zotero versions:
Zotero 2.1.10 and Zotero 3.0.b2
the latter one being the beta. If you have the beta version installed it will auto-update.
If not, finding out about it is a bit more tricky, as not every incremental release is announced on the blog. The beta generally is quite stable and the database is backwards compatible with Zotero 2.1.10, so the risk of switching to the beta isn't huge, but it _is_ a beta version.
I've set up a Zotero 3.0b2 test install, got the most recent APA v.6 citation style from the repository, and added another citation to a longish document with some 230 citations already in place.
Here's part of the output:
Smith, J. (1993af, November 22). Smith, J. (1993ag, November 27). Smith, J. (1993ah, December 8). Smith, J. (1993ai, December 13). Smith, J. (1994aj). Smith, J. (1994ak, March 20). Smith, J. (1994al, March 22). Smith, J. (1994am, April 26).
Also: I had some faint hope that the performance issue might disappear in the 3.0 beta -- it didn't: crunching through those 230+ citations still froze up Firefox and LibreOffice for a couple of minutes (Intel Core2 Duo CPU T7300, 2.00GHz). The old citation processor didn't have that performance issue.
At least the sort appears to be correct, so that's some progress. Can you export the full set of references as Zotero RDF and paste them as a public gist on http://gist.github.com/ so we can try to replicate the issue? If preferred, send me a message on zotero.org, and I can send along my email address.
On a quick check in my development client with the same 1.0.206 processor version used in Zotero 3.0b2, everything comes out correctly when I send an rtf bibliography of those items to the clipboard and open it in OpenOffice.
Is it an in-document bibliography only that gives the problem, or do you see it with a clipboard bib as well?
Clipboard bib comes out okay (tested only once, though).
There appears to be a pattern in in-document reference lists: when I insert a new citation, the disambiguation goes funky. So far, using the 3.0 beta, I've hit Refresh on funky disambiguations twice: first time, I got correct suffixes straight away (after quite some crunching, that is). Second time, I got the old error again:
this.state.registry.registry[mylds[i]] is undefined
Logging out of and back into the Gnome session, recovering the crashed .odt and hitting Refresh gave me a correct sort with correct disambiguation suffixes.
I'll take a look later this week. Offhand, the most likely culprit is previewing. To preview entries, we pull out and reinsert portions of the processor internal registry, to preserve state. There is a lot of fine-grained data involved, and it could be that a value somewhere is not getting restored properly. I see at least one function in there that could potentially be replaced with a conversion to and from JSON, which might be simpler. To test whether that will work, I'll need to make some changes to the test framework. We'll see what emerges.
Upgrade Storage
(1993p, December 8)
(1993q, April 8)
(1993r, December 18)
(1993s, February 27)
Sorry for the false alarm!
What might be going on here is failure to update the suffixes. In building this data set, were the strange suffixes ever valid for the relevant items at any point? Or did it just suddenly start apply incorrect suffixes willy-nilly?
(Edit: when you submit, send in the last reference in the series; that should pull in the data for all of the preceding items.)
Sometimes I can hit "Refresh" and get a perfectly normal rendering:
Smith, J. (1989, December 8).
Smith, J. (1990, May 10).
Smith, J. (1991a, February 26).
Smith, J. (1991b, June 14).
Smith, J. (1991c, August 30).
Smith, J. (1991d, October 1).
Smith, J. (1991e, December 25).
Smith, J. (1992, September 21).
Smith, J. (1993a).
Smith, J. (1993b, January 8).
Smith, J. (1993c, January 12).
Smith, J. (1993d, January 13).
Smith, J. (1993e, January 16).
Smith, J. (1993f, January 18).
Smith, J. (1993g, January 29).
[etc.]
It's soul-crushingly slow, however: The article has some 230 references, and refreshing them on a T61 Thinkpad takes five minutes during which Firefox and LibreOffice freeze up: at first it's Firefox that keeps hogging 100% of CPU for two minutes, then there's another three minutes during which CPU usage is way down but LibreOffice is frozen anyway, then eventually the process is done and the references are re-sorted fine.
I'm assuming the "feedback gadget thing" is the "Report Error..." feature under the cogwheel icon? After doing the Refresh reported above, there's nothing there: "Report Error..." is greyed out.
Zotero experienced an error updating your document
this.registry.citationByld[c[0]] is undefined.
Or:
Zotero experienced an error updating your document
this.state.registry.registry[mylds[i]] is undefined.
I then need to restart the X server, recover the crashed .odt document and get back to wherever I was.
I saw something similar recently during development work on the processor -- changes in rendering with repeated refreshes. The symptoms I saw have been fixed in the latest version. There have been some other small fixes as well, and you may seem an improvement in stability in the next Zotero release. The fixes won't help with your performance issues though. You might try switching to a style that is less heavily reliant on disambiguation while drafting -- one of the Chicago note styles might be a good candidate -- and switch to the production style for the final rendering.
Smith, J. (1993a, February 2).
Smith, J. (1995b, February 20).
Smith, J. (1995c, February 25).
Smith, J. (1995d, March 28).
Smith, J. (1995e, July 19).
Smith, J. (1995f, August 3).
Smith, J. (1996g, January 29).
Smith, J. (1996h, February 11).
Smith, J. (1996i, February 14).
Smith, J. (1996j, February 20).
Smith, J. (1996k, April 24).
Smith, J. (1997l, August 19).
Smith, J. (1997m, August 20).
Smith, J. (1997n, December 12).
Smith, J. (1997o, December 19).
Smith, J. (1998p, February 13).
Smith, J. (1998q, February 23).
Smith, J. (1999r, December).
I need to hit Refresh to get the correct output:
Smith, J. (1993, February 2).
Smith, J. (1995a, February 20).
Smith, J. (1995b, February 25).
Smith, J. (1995c, March 28).
Smith, J. (1995d, July 19).
Smith, J. (1995e, August 3).
Smith, J. (1996a, January 29).
Smith, J. (1996b, February 11).
Smith, J. (1996c, February 14).
Smith, J. (1996d, February 20).
Smith, J. (1996e, April 24).
Smith, J. (1997a, August 19).
Smith, J. (1997b, August 20).
Smith, J. (1997c, December 12).
Smith, J. (1997d, December 19).
Smith, J. (1998a, February 13).
Smith, J. (1998b, February 23).
Smith, J. (1999, December).
I can't hit Refresh right after getting the bad output, however, as this will give me an error. I need to shut everything down and restart the X server (closing and re-opening the document still results in the error. Closing and re-starting LibreOffice and then re-opening the document still results in the error).
Brooker, C. (2009a, January 5).
Brooker, C. (2009, August 22).
Brooker, C. (2011a, July 24).
Brooker, C. (2011b, July 31).
I'll build out the data set a bit and see if I can reproduce the disambiguation increments error from scratch.
Brooker, C. (2009a, January 5).
Brooker, C. (2009b, August 22).
Brooker, C. (2010, February 1).
Brooker, C. (2011c, July 24).
Brooker, C. (2011d, July 31).
While creating the sample, I saved, closed and re-opened the document after two or three citations, and then hit Refresh, which may or may not have had an effect on the final outcome.
this.state.registry.registry[mylds[i]] is undefined.
I reset the X server, started LibreOffice, waited for LibreOffice to recover the crashed document, hit Refresh once the document had loaded, and, hey -- perfect output:
Brooker, C. (2009a, January 5).
Brooker, C. (2009b, August 22).
Brooker, C. (2010, February 1).
Brooker, C. (2011a, July 24).
Brooker, C. (2011b, July 31).
Software versions, for what it may be worth: Zotero 2.1.10, Firefox 7.0.1, LibreOffice 3.3.4, Ubuntu 11.4
Frank
Bundling up a fresh processor release now, which should work its way into the next Zotero release.
Has the next Zotero release been scheduled yet?
Zotero 2.1.10 and Zotero 3.0.b2
the latter one being the beta. If you have the beta version installed it will auto-update.
If not, finding out about it is a bit more tricky, as not every incremental release is announced on the blog. The beta generally is quite stable and the database is backwards compatible with Zotero 2.1.10, so the risk of switching to the beta isn't huge, but it _is_ a beta version.
Here's part of the output:
Smith, J. (1993af, November 22).
Smith, J. (1993ag, November 27).
Smith, J. (1993ah, December 8).
Smith, J. (1993ai, December 13).
Smith, J. (1994aj).
Smith, J. (1994ak, March 20).
Smith, J. (1994al, March 22).
Smith, J. (1994am, April 26).
The new year (1994) still doesn't reset to "a".
Something is still broken.
Is it an in-document bibliography only that gives the problem, or do you see it with a clipboard bib as well?
There appears to be a pattern in in-document reference lists: when I insert a new citation, the disambiguation goes funky. So far, using the 3.0 beta, I've hit Refresh on funky disambiguations twice: first time, I got correct suffixes straight away (after quite some crunching, that is). Second time, I got the old error again:
this.state.registry.registry[mylds[i]] is undefined
Logging out of and back into the Gnome session, recovering the crashed .odt and hitting Refresh gave me a correct sort with correct disambiguation suffixes.