emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* [BUG?] subtle sequencing error when setting org-bbdb-old in org-bbdb.el
@ 2012-02-25  9:20 Nick Dokos
  2012-02-27 20:26 ` David Maus
  0 siblings, 1 reply; 6+ messages in thread
From: Nick Dokos @ 2012-02-25  9:20 UTC (permalink / raw)
  To: emacs-orgmode; +Cc: nicholas.dokos

I was bitten by this and it took me a while to figure out what was going
on, so maybe I can save somebody some time by recording the problem here.

I'm using bbdb 2.36devo (i.e. an old bbdb version - see below for my
3.0 troubles), and although org-bbdb-anniversaries was working fine,
bbdb links did not: C-c l on a bbdb entry would raise an error about
void function bbdb-record-get-field. Now org-bbdb-store-link contains
the following code

                    (if org-bbdb-old
                        (bbdb-record-getprop rec 'company)
                      (car (bbdb-record-get-field rec 'organization))

so clearly org-bbdb-old was nil - but why? It seemed to me that it should
be t since my bbdb was old.

It turns out that org-bbdb.el contains a line that sets org-bbdb-old
thus:

  (defvar org-bbdb-old (fboundp 'bbdb-record-get-field-internal))

Check whether an "old" bbdb function is present and if so, set
org-bbdb-old to t. Basically, the variable tells the rest of org-bbdb.el
whether one's bbdb is old (< 3.0) or not, so that it can use the proper
compatibility layer. This was not working in my case : the variable
resolutely held the value nil, no matter what requires/load-library/ etc
tricks I threw at it.

The problem was that org-bbdb is part of org-modules by default and that
was loading org-bbdb way too early, certainly before bbdb itself was
loaded.  That would set the value to nil and nothing I would do could
change it (short of whacking it with a setq).

My solution was to change the customization of org-modules to get rid of
org-bbdb there. I do things in the proper sequence in my initialization
files in any case, so there is no need to have it in org-modules.
But maybe there's a better solution?

Re: the bbdb 3.0 troubles. I have tried switching to bbdb 3.0
(specifically "BBDB version 3.02 ($Date: 2012/01/02 10:08:06 $)") but
I've been stymied so far with org-bbdb-anniversaries blowing up (a far
worse scenario than the link problem above - that's why I'm still using
2.36devo and went after the link fix first).

The error I get is "Debugger entered--Lisp error: (void-function
bbdb-record-getprop)" in org-bbdb-anniv-hash (see backtrace below),
but I haven't chased down that problem yet. But it seems there are
people using bbdb 3.0 so I'm wondering what's wrong with my setup.

Nick


---------------------------------------------------------------------------
Debugger entered--Lisp error: (void-function bbdb-record-getprop)
  (bbdb-record-getprop rec org-bbdb-anniversary-field)
  (setq annivs (bbdb-record-getprop rec org-bbdb-anniversary-field))
  (if (setq annivs (bbdb-record-getprop rec org-bbdb-anniversary-field)) (progn (setq annivs (bbdb-split annivs "\n")) (while annivs (setq split (org-bbdb-anniv-split (pop annivs))) (multiple-value-bind (m d y) (values-list (funcall org-bbdb-extract-date-fun (car split))) (setq tmp (gethash (list m d) org-bbdb-anniv-hash)) (puthash (list m d) (cons (list y (bbdb-record-name rec) (cadr split)) tmp) org-bbdb-anniv-hash)))))
  (when (setq annivs (bbdb-record-getprop rec org-bbdb-anniversary-field)) (setq annivs (bbdb-split annivs "\n")) (while annivs (setq split (org-bbdb-anniv-split (pop annivs))) (multiple-value-bind (m d y) (values-list (funcall org-bbdb-extract-date-fun (car split))) (setq tmp (gethash (list m d) org-bbdb-anniv-hash)) (puthash (list m d) (cons (list y (bbdb-record-name rec) (cadr split)) tmp) org-bbdb-anniv-hash))))
  (while --cl-dolist-temp-- (setq rec (car --cl-dolist-temp--)) (when (setq annivs (bbdb-record-getprop rec org-bbdb-anniversary-field)) (setq annivs (bbdb-split annivs "\n")) (while annivs (setq split (org-bbdb-anniv-split (pop annivs))) (multiple-value-bind (m d y) (values-list (funcall org-bbdb-extract-date-fun (car split))) (setq tmp (gethash (list m d) org-bbdb-anniv-hash)) (puthash (list m d) (cons (list y (bbdb-record-name rec) (cadr split)) tmp) org-bbdb-anniv-hash)))) (setq --cl-dolist-temp-- (cdr --cl-dolist-temp--)))
  (let ((--cl-dolist-temp-- (bbdb-records)) rec) (while --cl-dolist-temp-- (setq rec (car --cl-dolist-temp--)) (when (setq annivs (bbdb-record-getprop rec org-bbdb-anniversary-field)) (setq annivs (bbdb-split annivs "\n")) (while annivs (setq split (org-bbdb-anniv-split (pop annivs))) (multiple-value-bind (m d y) (values-list (funcall org-bbdb-extract-date-fun (car split))) (setq tmp (gethash (list m d) org-bbdb-anniv-hash)) (puthash (list m d) (cons (list y ... ...) tmp) org-bbdb-anniv-hash)))) (setq --cl-dolist-temp-- (cdr --cl-dolist-temp--))))
  (catch (quote --cl-block-nil--) (let ((--cl-dolist-temp-- (bbdb-records)) rec) (while --cl-dolist-temp-- (setq rec (car --cl-dolist-temp--)) (when (setq annivs (bbdb-record-getprop rec org-bbdb-anniversary-field)) (setq annivs (bbdb-split annivs "\n")) (while annivs (setq split (org-bbdb-anniv-split (pop annivs))) (multiple-value-bind (m d y) (values-list (funcall org-bbdb-extract-date-fun ...)) (setq tmp (gethash ... org-bbdb-anniv-hash)) (puthash (list m d) (cons ... tmp) org-bbdb-anniv-hash)))) (setq --cl-dolist-temp-- (cdr --cl-dolist-temp--)))))
  (cl-block-wrapper (catch (quote --cl-block-nil--) (let ((--cl-dolist-temp-- (bbdb-records)) rec) (while --cl-dolist-temp-- (setq rec (car --cl-dolist-temp--)) (when (setq annivs (bbdb-record-getprop rec org-bbdb-anniversary-field)) (setq annivs (bbdb-split annivs "\n")) (while annivs (setq split (org-bbdb-anniv-split ...)) (multiple-value-bind (m d y) (values-list ...) (setq tmp ...) (puthash ... ... org-bbdb-anniv-hash)))) (setq --cl-dolist-temp-- (cdr --cl-dolist-temp--))))))
  (block nil (let ((--cl-dolist-temp-- (bbdb-records)) rec) (while --cl-dolist-temp-- (setq rec (car --cl-dolist-temp--)) (when (setq annivs (bbdb-record-getprop rec org-bbdb-anniversary-field)) (setq annivs (bbdb-split annivs "\n")) (while annivs (setq split (org-bbdb-anniv-split (pop annivs))) (multiple-value-bind (m d y) (values-list (funcall org-bbdb-extract-date-fun ...)) (setq tmp (gethash ... org-bbdb-anniv-hash)) (puthash (list m d) (cons ... tmp) org-bbdb-anniv-hash)))) (setq --cl-dolist-temp-- (cdr --cl-dolist-temp--)))))
  (dolist (rec (bbdb-records)) (when (setq annivs (bbdb-record-getprop rec org-bbdb-anniversary-field)) (setq annivs (bbdb-split annivs "\n")) (while annivs (setq split (org-bbdb-anniv-split (pop annivs))) (multiple-value-bind (m d y) (values-list (funcall org-bbdb-extract-date-fun (car split))) (setq tmp (gethash (list m d) org-bbdb-anniv-hash)) (puthash (list m d) (cons (list y (bbdb-record-name rec) (cadr split)) tmp) org-bbdb-anniv-hash)))))
  (let (split tmp annivs) (clrhash org-bbdb-anniv-hash) (dolist (rec (bbdb-records)) (when (setq annivs (bbdb-record-getprop rec org-bbdb-anniversary-field)) (setq annivs (bbdb-split annivs "\n")) (while annivs (setq split (org-bbdb-anniv-split (pop annivs))) (multiple-value-bind (m d y) (values-list (funcall org-bbdb-extract-date-fun (car split))) (setq tmp (gethash (list m d) org-bbdb-anniv-hash)) (puthash (list m d) (cons (list y ... ...) tmp) org-bbdb-anniv-hash))))))
  org-bbdb-make-anniv-hash()
  (progn (org-bbdb-make-anniv-hash))
  (if (or org-bbdb-updated-p (= 0 (hash-table-count org-bbdb-anniv-hash))) (progn (org-bbdb-make-anniv-hash)))
  (when (or org-bbdb-updated-p (= 0 (hash-table-count org-bbdb-anniv-hash))) (org-bbdb-make-anniv-hash))
  org-bbdb-anniversaries()

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [BUG?] subtle sequencing error when setting org-bbdb-old in org-bbdb.el
  2012-02-25  9:20 [BUG?] subtle sequencing error when setting org-bbdb-old in org-bbdb.el Nick Dokos
@ 2012-02-27 20:26 ` David Maus
  2012-02-27 20:44   ` Nick Dokos
  2012-02-27 22:21   ` Nick Dokos
  0 siblings, 2 replies; 6+ messages in thread
From: David Maus @ 2012-02-27 20:26 UTC (permalink / raw)
  To: nicholas.dokos; +Cc: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 2520 bytes --]

Hi Nick,

At Sat, 25 Feb 2012 04:20:10 -0500,
Nick Dokos wrote:
>
> I was bitten by this and it took me a while to figure out what was going
> on, so maybe I can save somebody some time by recording the problem here.
>
> I'm using bbdb 2.36devo (i.e. an old bbdb version - see below for my
> 3.0 troubles), and although org-bbdb-anniversaries was working fine,
> bbdb links did not: C-c l on a bbdb entry would raise an error about
> void function bbdb-record-get-field. Now org-bbdb-store-link contains
> the following code
>
>                     (if org-bbdb-old
>                         (bbdb-record-getprop rec 'company)
>                       (car (bbdb-record-get-field rec 'organization))
>
> so clearly org-bbdb-old was nil - but why? It seemed to me that it should
> be t since my bbdb was old.
>
> It turns out that org-bbdb.el contains a line that sets org-bbdb-old
> thus:
>
>   (defvar org-bbdb-old (fboundp 'bbdb-record-get-field-internal))
>
> Check whether an "old" bbdb function is present and if so, set
> org-bbdb-old to t. Basically, the variable tells the rest of org-bbdb.el
> whether one's bbdb is old (< 3.0) or not, so that it can use the proper
> compatibility layer. This was not working in my case : the variable
> resolutely held the value nil, no matter what requires/load-library/ etc
> tricks I threw at it.
>
> The problem was that org-bbdb is part of org-modules by default and that
> was loading org-bbdb way too early, certainly before bbdb itself was
> loaded.  That would set the value to nil and nothing I would do could
> change it (short of whacking it with a setq).

I pushed a patch that should fix this problem. I wrapped a
`eval-after-load' around the `defvar', this should make sure that the
variable is set after bbdb was loaded.

>
> Re: the bbdb 3.0 troubles. I have tried switching to bbdb 3.0
> (specifically "BBDB version 3.02 ($Date: 2012/01/02 10:08:06 $)") but
> I've been stymied so far with org-bbdb-anniversaries blowing up (a far
> worse scenario than the link problem above - that's why I'm still using
> 2.36devo and went after the link fix first).
>
> The error I get is "Debugger entered--Lisp error: (void-function
> bbdb-record-getprop)" in org-bbdb-anniv-hash (see backtrace below),
> but I haven't chased down that problem yet. But it seems there are
> people using bbdb 3.0 so I'm wondering what's wrong with my setup.

Can't comment on this.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de

[-- Attachment #2: Type: application/pgp-signature, Size: 230 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [BUG?] subtle sequencing error when setting org-bbdb-old in org-bbdb.el
  2012-02-27 20:26 ` David Maus
@ 2012-02-27 20:44   ` Nick Dokos
  2012-02-27 22:21   ` Nick Dokos
  1 sibling, 0 replies; 6+ messages in thread
From: Nick Dokos @ 2012-02-27 20:44 UTC (permalink / raw)
  To: David Maus; +Cc: nicholas.dokos, emacs-orgmode

David Maus <dmaus@ictsoc.de> wrote:

> >
> > The problem was that org-bbdb is part of org-modules by default and that
> > was loading org-bbdb way too early, certainly before bbdb itself was
> > loaded.  That would set the value to nil and nothing I would do could
> > change it (short of whacking it with a setq).
> 
> I pushed a patch that should fix this problem. I wrapped a
> `eval-after-load' around the `defvar', this should make sure that the
> variable is set after bbdb was loaded.
> 

Thanks! I'll try to take it out for a spin in the next few days.

> >
> > Re: the bbdb 3.0 troubles. I have tried switching to bbdb 3.0
> > (specifically "BBDB version 3.02 ($Date: 2012/01/02 10:08:06 $)") but
> > I've been stymied so far with org-bbdb-anniversaries blowing up (a far
> > worse scenario than the link problem above - that's why I'm still using
> > 2.36devo and went after the link fix first).
> >
> > The error I get is "Debugger entered--Lisp error: (void-function
> > bbdb-record-getprop)" in org-bbdb-anniv-hash (see backtrace below),
> > but I haven't chased down that problem yet. But it seems there are
> > people using bbdb 3.0 so I'm wondering what's wrong with my setup.
> 
> Can't comment on this.
> 

Understood. I hope to get bbdb-3.x up and running and then see what (if
anything) is broken with org-bbdb, but at this point, it's just as likely
that I'm doing something wrong - I just haven't had the time to dig into it
seriously.

Nick

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [BUG?] subtle sequencing error when setting org-bbdb-old in org-bbdb.el
  2012-02-27 20:26 ` David Maus
  2012-02-27 20:44   ` Nick Dokos
@ 2012-02-27 22:21   ` Nick Dokos
  2012-03-02 16:32     ` David Maus
  1 sibling, 1 reply; 6+ messages in thread
From: Nick Dokos @ 2012-02-27 22:21 UTC (permalink / raw)
  To: David Maus; +Cc: nicholas.dokos, emacs-orgmode

David Maus <dmaus@ictsoc.de> wrote:

> > The problem was that org-bbdb is part of org-modules by default and that
> > was loading org-bbdb way too early, certainly before bbdb itself was
> > loaded.  That would set the value to nil and nothing I would do could
> > change it (short of whacking it with a setq).
> 
> I pushed a patch that should fix this problem. I wrapped a
> `eval-after-load' around the `defvar', this should make sure that the
> variable is set after bbdb was loaded.
> 

I still have a problem with one configuration (but not with another),
but I haven't drilled down to figure out what the problem is. I was
wondering however if the eval-after-load should be predicated on
bbdb-com rather than bbdb[fn:1]: with this change, both of my tested
configurations work (hardly a definitive test but perhaps better than
nothing).

Nick

Footnotes:

[fn:1] ... the reason being that the fboundp test is on
       bbdb-record-get-field-internal, which is defined in bbdb-com.el.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [BUG?] subtle sequencing error when setting org-bbdb-old in org-bbdb.el
  2012-02-27 22:21   ` Nick Dokos
@ 2012-03-02 16:32     ` David Maus
  2012-03-02 17:49       ` Nick Dokos
  0 siblings, 1 reply; 6+ messages in thread
From: David Maus @ 2012-03-02 16:32 UTC (permalink / raw)
  To: nicholas.dokos; +Cc: David Maus, emacs-orgmode

At Mon, 27 Feb 2012 17:21:59 -0500,
Nick Dokos wrote:
> 
> David Maus <dmaus@ictsoc.de> wrote:
> 
> > > The problem was that org-bbdb is part of org-modules by default and that
> > > was loading org-bbdb way too early, certainly before bbdb itself was
> > > loaded.  That would set the value to nil and nothing I would do could
> > > change it (short of whacking it with a setq).
> > 
> > I pushed a patch that should fix this problem. I wrapped a
> > `eval-after-load' around the `defvar', this should make sure that the
> > variable is set after bbdb was loaded.
> > 
> 
> I still have a problem with one configuration (but not with another),
> but I haven't drilled down to figure out what the problem is. I was
> wondering however if the eval-after-load should be predicated on
> bbdb-com rather than bbdb[fn:1]: with this change, both of my tested
> configurations work (hardly a definitive test but perhaps better than
> nothing).

Thanks for the feedback. Eval after load 'bbdb-com would have been
better -- I just replaced the entire defvar by a check in
`org-bbdb-open' and `org-bbdb-store-link' for the required functions.

So this should really work now.

Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [BUG?] subtle sequencing error when setting org-bbdb-old in org-bbdb.el
  2012-03-02 16:32     ` David Maus
@ 2012-03-02 17:49       ` Nick Dokos
  0 siblings, 0 replies; 6+ messages in thread
From: Nick Dokos @ 2012-03-02 17:49 UTC (permalink / raw)
  To: David Maus; +Cc: nicholas.dokos, emacs-orgmode

David Maus <dmaus@ictsoc.de> wrote:

> At Mon, 27 Feb 2012 17:21:59 -0500,
> Nick Dokos wrote:
> > 
> > David Maus <dmaus@ictsoc.de> wrote:
> > 
> > > > The problem was that org-bbdb is part of org-modules by default and that
> > > > was loading org-bbdb way too early, certainly before bbdb itself was
> > > > loaded.  That would set the value to nil and nothing I would do could
> > > > change it (short of whacking it with a setq).
> > > 
> > > I pushed a patch that should fix this problem. I wrapped a
> > > `eval-after-load' around the `defvar', this should make sure that the
> > > variable is set after bbdb was loaded.
> > > 
> > 
> > I still have a problem with one configuration (but not with another),
> > but I haven't drilled down to figure out what the problem is. I was
> > wondering however if the eval-after-load should be predicated on
> > bbdb-com rather than bbdb[fn:1]: with this change, both of my tested
> > configurations work (hardly a definitive test but perhaps better than
> > nothing).
> 
> Thanks for the feedback. Eval after load 'bbdb-com would have been
> better -- I just replaced the entire defvar by a check in
> `org-bbdb-open' and `org-bbdb-store-link' for the required functions.
> 
> So this should really work now.
> 

It does, at least in the two configurations I've tested: my full-blown one
and a minimal org one with bbdb loaded after the fact.

I'll be trying it with bbdb 3.x some time soon, I hope.

Thanks very much!
Nick

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2012-03-02 17:49 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-25  9:20 [BUG?] subtle sequencing error when setting org-bbdb-old in org-bbdb.el Nick Dokos
2012-02-27 20:26 ` David Maus
2012-02-27 20:44   ` Nick Dokos
2012-02-27 22:21   ` Nick Dokos
2012-03-02 16:32     ` David Maus
2012-03-02 17:49       ` Nick Dokos

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).