Re: Bibdesk-users Digest, Vol 45, Issue 9

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-users Digest, Vol 45, Issue 9

C.H.E.


[hidden email] wrote:

>Send Bibdesk-users mailing list submissions to
> [hidden email]
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/bibdesk-users
>or, via email, send a message with subject or body 'help' to
> [hidden email]
>
>You can reach the person managing the list at
> [hidden email]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Bibdesk-users digest..."
>
>Today's Topics:
>
>   1. Re: Bibliographic Database (Adam R. Maxwell)
>   2. Re: Bibliographic Database (Fischlin Andreas)
>   3. Re: Bibliographic Database (Adam R. Maxwell)
>   4. pdf importing and filing question (Josef Trapani)
>   5. Re: pdf importing and filing question (Christiaan Hofman)
>   6. Re: pdf importing and filing question (Jason Davies)
>   7. Re: pdf importing and filing question (Josef Trapani)
>
>
>On Jan 8, 2010, at 12:45 AM, Fischlin Andreas wrote:
>
>> My personal data base has 13'591 records and I do not know how sluggish BD would get if I would transfer all records to it.
>
>File a bug with a sample if it's slow.  The largest file I tested with has ~25000 entries, and the only slowdowns I recall were in searching (fixed) and smart groups (which you can now hide in the source list).
>
>
>
>
>
>On 08/Jan/2010, at 16:19 , Adam R. Maxwell wrote:
>
>>
>> On Jan 8, 2010, at 12:45 AM, Fischlin Andreas wrote:
>>
>>> My personal data base has 13'591 records and I do not know how  
>>> sluggish BD would get if I would transfer all records to it.
>>
>> File a bug with a sample if it's slow.  The largest file I tested  
>> with has ~25000 entries, and the only slowdowns I recall were in  
>> searching (fixed) and smart groups (which you can now hide in the  
>> source list).
>
>Good to know. Also all with abstracts? I just didn't dare to test it.  
>Will do some times in the future when I have some minutes to spare.
>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast  
>> and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Bibdesk-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/bibdesk-users
>
>
>
>
>
>On Jan 9, 2010, at 8:05 AM, Fischlin Andreas wrote:
>
>> On 08/Jan/2010, at 16:19 , Adam R. Maxwell wrote:
>>
>>> On Jan 8, 2010, at 12:45 AM, Fischlin Andreas wrote:
>>>
>>>> My personal data base has 13'591 records and I do not know how  
>>>> sluggish BD would get if I would transfer all records to it.
>>>
>>> File a bug with a sample if it's slow.  The largest file I tested  
>>> with has ~25000 entries, and the only slowdowns I recall were in  
>>> searching (fixed) and smart groups (which you can now hide in the  
>>> source list).
>>
>> Good to know. Also all with abstracts?
>
>I don't know.  It's also been a couple of years since I did that profiling, and lots of things have changed.
>
>> I just didn't dare to test it.  
>> Will do some times in the future when I have some minutes to spare.
>
>You can only find problems by testing, but here are my guesses: having abstracts in all of them would increase the memory footprint, and make searching by "any field" somewhat slower.  If you have sufficient RAM and multiple cores, you won't notice that.  Smart groups that depend on abstract would likely be slow.
>
>
>
>
>
>Greetings,
>
>I am currently managing my PDF files by auto filing them in a specific folder and naming them by the associated reference's Pmid (Pubmed ID).
>In order to fulfill the Auto File Local File Format rules my format string is: %f{Pmid}0%n[_]0.pdf
>With the %n[_]0 I end up with duplicates of the same pdf if I accidentally drag the same pdf into bibdesk a second (or third) time.
>This often happens because my Auto File folder has 2,600 pdf files in it.
>
>I have three questions:
>
>1) Is there a way for Import Publications to scan my reference library to determine if I have already have a reference for the incoming pdf? Currently, when I download a pdf that I think I don't have (but actually do) and drag it onto my large primary .bib file I end up with a duplicate pdf file with _0 added to the filename (as per my format string).
>
>2) Is there a way to make Import Publications scan my Auto File folder to determine if the pdf that I am importing already exists? Currently, if I am working with a smaller .bib reference list dragging in a given pdf is very useful to populate that reference into my .bib file, but if I already have the pdf then I don't necessarily need another copy in my Auto File Folder. This can occur when someone has emailed me a pdf and I want to import it into a unique .bib file.
>
>It seems that 1) and 2) could be accomplished in the same task, first scanning whether or not the incoming pdf's associated reference exists, and adding it if it doesn't, and then determining if the pdf already exists and adding it if it doesn't.
>
>3) Is there a way to scan all existing references in a .bib file and auto-associate pdf's from the Auto File Folder to references with matching Pmid's (or other unique identifier)? This happens when I create a new bib file with new references and I already have pdf's in my Auto File Folder. This is different from question 2) because here the reference already exists in the file and the pdf may already exist in the folder.
>
>I have a script hook to compare an incoming pdf filename with all pdf file names in my Auto File Folder, however the Import Publications feature overrides any attempt at stopping a pdf's auto filing or a reference's creation.
>
>Many thanks for any and all advice,
>Joe
>
>
>
>
>
>
>
>On Jan 12, 2010, at 1:51, Josef Trapani wrote:
>
>> Greetings,
>>
>> I am currently managing my PDF files by auto filing them in a specific folder and naming them by the associated reference's Pmid (Pubmed ID).
>> In order to fulfill the Auto File Local File Format rules my format string is: %f{Pmid}0%n[_]0.pdf
>> With the %n[_]0 I end up with duplicates of the same pdf if I accidentally drag the same pdf into bibdesk a second (or third) time.
>> This often happens because my Auto File folder has 2,600 pdf files in it.
>>
>> I have three questions:
>>
>> 1) Is there a way for Import Publications to scan my reference library to determine if I have already have a reference for the incoming pdf? Currently, when I download a pdf that I think I don't have (but actually do) and drag it onto my large primary .bib file I end up with a duplicate pdf file with _0 added to the filename (as per my format string).
>
>Most definitely not. Especially when you're talking about "duplicate" rather than "identical" files (which I think you are.)
>
>>
>> 2) Is there a way to make Import Publications scan my Auto File folder to determine if the pdf that I am importing already exists? Currently, if I am working with a smaller .bib reference list dragging in a given pdf is very useful to populate that reference into my .bib file, but if I already have the pdf then I don't necessarily need another copy in my Auto File Folder. This can occur when someone has emailed me a pdf and I want to import it into a unique .bib file.
>>
>
>Same answer.
>
>> It seems that 1) and 2) could be accomplished in the same task, first scanning whether or not the incoming pdf's associated reference exists, and adding it if it doesn't, and then determining if the pdf already exists and adding it if it doesn't.
>>
>
>Except that it would be extremely and prohibitively inefficient, so we can't do that.
>
>> 3) Is there a way to scan all existing references in a .bib file and auto-associate pdf's from the Auto File Folder to references with matching Pmid's (or other unique identifier)? This happens when I create a new bib file with new references and I already have pdf's in my Auto File Folder. This is different from question 2) because here the reference already exists in the file and the pdf may already exist in the folder.
>>
>
>Not for PMID. There is a way to try to match pubs and (unattached) files based on author names using the Match Files feature.
>
>> I have a script hook to compare an incoming pdf filename with all pdf file names in my Auto File Folder, however the Import Publications feature overrides any attempt at stopping a pdf's auto filing or a reference's creation.
>>
>> Many thanks for any and all advice,
>> Joe
>>
>
>When you're using auto-filing, comparing file names is completely useless.
>
>Christiaan
>
>
>
>On 12 Jan 2010, at 01:15, Christiaan Hofman wrote:
>
>>> With the %n[_]0 I end up with duplicates of the same pdf if I accidentally drag the same pdf into bibdesk a second (or third) time.
>>> This often happens because my Auto File folder has 2,600 pdf files in it.
>
>sounds like a folder action might work if you can get the syntax of searching for a file. I don't know if a folder action could interrupt BibDesk's operation but it could give you a dialog box alerting you. or (more basic) reveal the new file in the Finder so you can see for yourself (ie every time you drop a file on BD, it would show you the resulting file. That would be a mix of efficiency (no real work for the CPU) and what you need?
>
>
>Thanks Jason,
>
>Here's the folder script I attached to my Autofile Folder:
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>property dialog_timeout : 30 -- set the amount of time before dialogs auto-answer.
>on adding folder items to this_folder after receiving added_item
> try
> --generate list of PDF files in Auto File folder
> tell application "Finder"
> set Alist to name of every file of folder this_folder as text
> end tell
> set thePath to POSIX path of added_item
> set AppleScript's text item delimiters to "/"
> set thefilename to text item -1 of thePath
> --assuming auto file file format adds an underscore (_01) when duplicating a pdf
> set AppleScript's text item delimiters to "_"
> set theshortfilename to (text item -1 of thefilename) as text
> if theshortfilename is in Alist then
> set the alert_message to "This PDF exists, would you like to see the copy?"
> display dialog the alert_message buttons {"Yes", "No"} default button 2 with icon 1 giving up after dialog_timeout
> set the user_choice to the button returned of the result
> if user_choice is "Yes" then
> tell application "Finder"
> activate
> open this_folder
> reveal the added_item
> end tell
> end if
> end if
> end try
>end adding folder items to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
>
>
>On Jan 11, 2010, at 5:34 PM, Jason Davies wrote:
>
>>
>> On 12 Jan 2010, at 01:15, Christiaan Hofman wrote:
>>
>>>> With the %n[_]0 I end up with duplicates of the same pdf if I accidentally drag the same pdf into bibdesk a second (or third) time.
>>>> This often happens because my Auto File folder has 2,600 pdf files in it.
>>
>> sounds like a folder action might work if you can get the syntax of searching for a file. I don't know if a folder action could interrupt BibDesk's operation but it could give you a dialog box alerting you. or (more basic) reveal the new file in the Finder so you can see for yourself (ie every time you drop a file on BD, it would show you the resulting file. That would be a mix of efficiency (no real work for the CPU) and what you need?
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev 
>> _______________________________________________
>> Bibdesk-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/bibdesk-users
>
>
>------------------------------------------------------------------------------
>This SF.Net email is sponsored by the Verizon Developer Community
>Take advantage of Verizon's best-in-class app development support
>A streamlined, 14 day to market process makes app distribution fast and easy
>Join now and get one step closer to millions of Verizon customers
>http://p.sf.net/sfu/verizon-dev2dev 
>_______________________________________________
>Bibdesk-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/bibdesk-users
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Bibdesk-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users