On Nov 10 2012 8:51 AM, Morten Omholt Alver wrote:
> On 10 November 2012 16:19, Rich Shepard <[email protected]> 
> wrote:
>
>> On Sat, 10 Nov 2012, Oliver wrote:
>>
>> > Could you send us a sequence of commands which cause the issue.
>>
>> Oliver,
>>
>>    The sequence you describe works for me, too. Before I started 
>> with
>> jabref
>> Thursday I had begun using bibus (written in python and wxpython). 
>> When I
>> could not find hot to add key words (using the RIS terminology) and 
>> could
>> not find any documentation or responses from the mail list I knew it 
>> was
>> time to find a tool better suited to my needs. JabRef is that tool.
>>
>>    So, I exported the couple of dozen rows from the bibus database 
>> in RIS
>> format and imported them into JabRef. Since I could now enter the 
>> key words
>> I started doing so and that's when I encountered the 
>> timing/concurrency
>> issue. I'd add key words for a row, close the window, and 
>> immediately click
>> on the following row. I could not get the entry window to 
>> immediately
>> display. Then I discovered that pausing between closing the entry 
>> window
>> for
>> one row and left-clicking on the next row opened the entry window; 
>> so did
>> keeping the entry window open and clicking on the next row.
>>
>>    This timing/concurrency issue probably shows only when multiple 
>> new
>> entries are imported and the user (perhaps as naive as I) tries to 
>> modify
>> each of them sequentially.
>>
>
> If I'm understanding this correctly (you are importing a number of 
> entries,
> then opening the entry editor sequentially for the entries and 
> modifying
> the keywords field in the General tab), this is a perfectly normal 
> way of
> using JabRef, and is definitely supposed to work fine.
>
> To rule out any double-clicking issues, could you try to do the same, 
> only
> selecting the row and using Ctrl-E to open the entry editor instead 
> of
> double-clicking?

Also, what version/revision are you using?  I'm currently running 
2.8.1, and in an attempt to reproduce the issue I first took a small bib 
with 9 entries, copied it and removed all the keys, then ran it through 
jabref -- no problems.  Then thinking that it might be an issue with the 
number of entries, I concatenated several of my bibs (over 1000 
entries), and did the same at the bottom.  I was able to click, generate 
the key, click and generate a key....  No problems there.  I did find 
two problems, one of which might be what you are seeing --

Now if I open up the editor window and sellect multiple entries and 
then type ^g, it only updates the last entry I chose, but confuses the 
editor window making it look like it put the key for the last entry in 
the entry for the first entry.  If I then go and click some place else 
and back again on the first entry, it shows that no key was generated.  
Now compare that to not having the editor window open, selecting 
multiple entries, and they all get updated properly.

My guess is that the editor window is either using a distributed 
variable and the read/write is not bound with concurrency control, or 
that it is using a cached variable which is not resynced until you 
change context.

hope that helps.

   EBo --

ps: the second problem was generating keys for 900  year old Sanscrit 
manuscript which has all sorts of fun things in the authors names that 
makes it imposible to guess the key name...

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Jabref-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jabref-users

Reply via email to