BBDB v3 Parse Error

[ddohe...@gmail.com]

I just added a new contact via Gnus bbdb, and when I try to sync I am getting the following

<code>
[16:10:08.402 INFO] Logging into Google...
[16:10:09.075 INFO] Parsing BBDB file /home/ded/.bbdb...
[16:10:09.075 INFO] Parsing BBDB Store with encoding utf-8...
[16:10:09.095 ERROR] Could not parse BBDB record: [#("SellerOf" 0 4 (fontified nil)) #("Ferrari" 0 7 (fontified nil)) nil nil nil nil nil (#("YY...@XXXXXXo.it" 0 21 (fontified nil))) ((creation-date . "2013-01-10 20:35:35 +0000") (timestamp . "2013-01-10 20:35:35 +0000") (subjects . "emacs mylin-like tool ?") (newsgroups . "gnu.emacs.help")) nil]

Traceback (most recent call last):
File "./asynk.py", line 892, in <module>
main()
File "./asynk.py", line 110, in main
asynk.dispatch()
File "./asynk.py", line 411, in dispatch
res = getattr(self, self.get_op())()
File "./asynk.py", line 620, in op_sync
pname = self._load_profile()
File "./asynk.py", line 886, in _load_profile
self._login()
File "./asynk.py", line 316, in _login
self.set_db(db2id, getattr(self, login_func)())
File "./asynk.py", line 832, in login_bb
bb = BBPIMDB(conf, bbfn)
File "/home/ded/src/ASynK/asynk/pimdb_bb.py", line 371, in __init__
def_ms = self.add_msgstore(def_fn)
File "/home/ded/src/ASynK/asynk/pimdb_bb.py", line 421, in add_msgstore
ms = MessageStore(self, ms)
File "/home/ded/src/ASynK/asynk/pimdb_bb.py", line 47, in __init__
self.populate_folders()
File "/home/ded/src/ASynK/asynk/pimdb_bb.py", line 314, in populate_folders
encoding=encoding)
File "/home/ded/src/ASynK/asynk/pimdb_bb.py", line 263, in parse_with_encoding
'processing file "%s" ') % fn)
pimdb_bb.BBDBFileFormatError: Cannot proceed with processing file "/home/ded/.bbdb"
</code>

Any idea what is causing this?

BTW, just learned about Asynk. Thanks for tackling this.

Regards,

Dan

[Sriram Karra]

On Fri, Jan 11, 2013 at 3:44 AM, <ddohe...@gmail.com> wrote:

[16:10:09.095    ERROR] Could not parse BBDB record: [#("SellerOf" 0 4 (fontified nil)) #("Ferrari" 0 7 (fontified nil)) nil nil nil nil nil (#("YY...@XXXXXXo.it" 0 21 (fontified nil))) ((creation-date . "2013-01-10 20:35:35 +0000") (timestamp . "2013-01-10 20:35:35 +0000") (subjects . "emacs mylin-like tool ?") (newsgroups . "gnu.emacs.help")) nil]

Dan, 

ASynK does not understand the lisp syntax sequences involving #. I have been meaning to look into this and add support, but not found the time. Can you purge your BBDB of such sequences and try? You could just try with a single BBDB entry to validate this hypothesis.

-Karra

[ddohe...@gmail.com]

Thanks, Karra. I would be glad to, but I'm only an amateur lisp hacker.

1. What is the correct way to transform the syntax to #-less?

2. BBDBv3 did it behind my back to begin with. Any way to stop that from happening?

Regards,

[ddohe...@gmail.com]

Karra,

I have done some investigating:

1. The #(...) form is a vector in lisp.
2. A record created from Gnus on the fly by hitting ':' appears to
create records in this form.
3. If the vector-form field is edited by hand, BBDBv3 writes it as a
string.

I've looked through bbdb.el to see if there was some setting that
could turn off vector-form writing in the db, but have found none.

If there were such a flag, that would probably be the best option.

From Asynk's point of view, however, it would seem that simply
extracting the first element of the vector would work. They appear to
have the following form:

#("Daniel" 0 6 (fontified nil))

The first element is the bare string, the second and third the first
and last index into the string, and the fourth some sort of fontifying
information that would appear to have no business in the db.

The same form appears to be used for all the fields generated during a
capture of the contact from the MUA.

Hope this helps a bit.

Regards,

[Sriram Karra]

On Fri, Jan 11, 2013 at 5:50 PM, <ddohe...@gmail.com> wrote:

Karra,

I've looked through bbdb.el to see if there was some setting that
could turn off vector-form writing in the db, but have found none.

If there were such a flag, that would probably be the best option.

Thank you for digging into this. I agree that turning off the code that is generating such syntax is the best way. It is the safest thing to do for reasons explained below.

 

From Asynk's point of view, however, it would seem that simply
extracting the first element of the vector would work.  They appear to
have the following form:

#("Daniel" 0 6 (fontified nil))

The first element is the bare string, the second and third the first
and last index into the string, and the fourth some sort of fontifying
information that would appear to have no business in the db.

In this particular instance, I suppose there is nothing to lose by dropping this fontification info. But I would be wary of doing this for all vector forms in this context. 

One of the main goals of ASynK is to avoid loss of information at all costs - even when Google Contacts does not support a certain paradigm (like Google Contacts only allows for one 'Organization', whereas BBDB allows for many. ASynK handles such cases gracefully by saving the additional organizations in custom fields in your Google Contact, and restoring it correctly in BBDB on the return journey). 

So I am reluctant to implement the hack you have suggested.

[Sriram Karra]

On Fri, Jan 11, 2013 at 5:50 PM, <ddohe...@gmail.com> wrote:

 

2. A record created from Gnus on the fly by hitting ':' appears to
   create records in this form.

Hey, what is the ":" key bound to? It does not do anything for me while using Ma Gnus v0.2 and an early version of BBDB v3.

[Daniel E. Doherty]

Sriram Karra <karr...@gmail.com> writes:

Sriram,

I am using BBDB v3. I don't see where I customized it, but here is what I get
when I look at the binding:

/==============================================================================\
| : runs the command bbdb-mua-display-sender, which is an interactive compiled |
| Lisp function in `bbdb-mua.el'. |
| |
| It is bound to :. |
| |
| (bbdb-mua-display-sender &optional UPDATE-P) |
| |
| Display the BBDB record(s) for the sender of this message. UPDATE-P may |
| take the same values as `bbdb-update-records-p'. For interactive calls, see |
| function `bbdb-mua-update-interactive-p'. |
\==============================================================================/

Actually, here is what I have in my init file:

/==========================================================================\
| When using ':' in summary, ask to create the record if it does not exist |
| (setq bbdb-mua-update-interactive-p '(query . query)) |
\==========================================================================/

My goal is to have bbdb collent only those contacts that I cherry-pick manually
with the ':' key, and not do automatic harvesting of emails. My old BBDB file
had literally thousands of spam-esque contacts that would have made syncing with
Google screw up the google side of things. So I cleaned it up before trying
asnk.

Hope this helps.

--
====================================================
Daniel E. Doherty
Law Offices of Daniel E. Doherty
7300 W. 110th Street, Suite 930
Overland Park, KS 66210
913.338.7182 (Phone)
913.338.7164 (FAX)
ded...@ddoherty.net

[Sriram Karra]

Daniel,

If you are on the bbdb-info list you might have see a conversation on the topic of these font properties in the bbdb database. There is no total clarity here, but it turns out that properties can get persisted by use of the substring and buffer-substring functions instead of substring-no-properties and buffer-substring-no-properties function. There are quite a few uses of the with-properties versions in BBDB.

Can you try a quick experiment: in file bbdb.el there is a function called 'bbdb-divide-name'. Can you convert the substring function invocations with the corresponding -no-properties versions? My gut feeling is that this should fix this for you - for new inserts, of course.

I am sure we can find a way to clean up your existing records, but first I would like to see how we can prevent ongoing pollution :)