From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: [BUG] org-clock-sum cannot handle headings with more than 29 stars (was: Re: How to debug "org-clock-display: Args out of range: [48230 48230) 48230 38618 38618 0 0 0 0 0 ...], 61" Date: Sat, 14 Jan 2012 13:49:22 -0500 Message-ID: <8789.1326566962@alphaville1> References: <20120106002125.GA32086@shi.workgroup> <8762gp3aqz.fsf@norang.ca> <20120112214110.GB29496@shi.workgroup> <4047.1326406324@alphaville1> <5046.1326408982@alphaville1> <20120114161631.GC7727@shi.workgroup> Reply-To: nicholas.dokos@hp.com Return-path: Received: from eggs.gnu.org ([140.186.70.92]:41949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rm93F-0008AK-5i for emacs-orgmode@gnu.org; Sat, 14 Jan 2012 14:14:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rm93D-0003oS-GP for emacs-orgmode@gnu.org; Sat, 14 Jan 2012 14:14:04 -0500 Received: from g1t0028.austin.hp.com ([15.216.28.35]:21288) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rm93D-0003LJ-Am for emacs-orgmode@gnu.org; Sat, 14 Jan 2012 14:14:03 -0500 Received: from g1t0038.austin.hp.com (g1t0038.austin.hp.com [16.236.32.44]) by g1t0028.austin.hp.com (Postfix) with ESMTP id 532201C0A7 for ; Sat, 14 Jan 2012 18:49:27 +0000 (UTC) In-Reply-To: Message from Gregor Zattler of "Sat, 14 Jan 2012 17:16:31 +0100." <20120114161631.GC7727@shi.workgroup> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode Cc: nicholas.dokos@hp.com Gregor Zattler wrote: > Hi Nick, org developers, > > while preparing a "minimal" example of my problem I finally > realised that "61" was the deepest level of indentation of some > inline tasks in my org file. When I wrote them I only remembered > inline tasks as with more than x stars and so I provided more > than enough :-) > > But this also applies to normal headings. My Minimal org file to > demonstrate the bug is now: > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > * dog > ** dog > *** dog > **** dog > ***** dog > ****** dog > ******* dog > ******** dog > ********* dog > ********** dog > *********** dog > ************ dog > ************* dog > ************** dog > *************** dog > **************** dog > ***************** dog > ****************** dog > ******************* dog > ******************** dog > ********************* dog > ********************** dog > *********************** dog > ************************ dog > ************************* dog > ************************** dog > *************************** dog > **************************** dog > ***************************** dog > ****************************** ant > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > doing M-x org-clock-display (which in turn execs org-clock-sum) > will fail. It will not fail, with the last line removed. > > I searched a bit in the sources (max.*level") but did not find > documentation regarding the maximum number of stars in org > files. Perhaps it has to be documented or "lmax" raised in the sources. > > Thanks for your help though, I first changed lmax as you proposed > and it fixed the problem. > > Ciao; gregor > > * Nick Dokos [12. Jan. 2012]: > > Nick Dokos wrote: > >> Gregor Zattler wrote: > >>> Debugger entered--Lisp error: (args-out-of-range [49569 49569 49569 39957 3= > >>> 9957 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] 61) > >>> aref([49569 49569 49569 39957 39957 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0= > >>> 0 0 0 0 0 0] 61) > >> > >> This tries to get the 61st element of a vector that has at most 30 or so > >> elements, hence the complaint. But of course, that's hardly > >> enlightening. However, the backtrace shows that this code is inside the > >> function org-clock-sum (in org-clock.el). And if you look at that > >> function, you see (where I have elided large swathes of code): > >> > >> (let* (... > >> (lmax 30) > >> (ltimes (make-vector lmax 0)) > >> ... > >> > >> So ltimes is a vector with *exactly* 30 elements. I would change that 30 > >> to 100 or so (something greater than 61 in any case) and retest. If that > >> fixes it, then we know the culprit and then we can dedice which is the > >> unreasonable one: the code or your subtree :-) > > Or maybe that 61 is way off base. After all, there are only 5 non-trivial > > entries in the vector. > > > > The code that sets the level seems suspect to me: > > > > (let* ((headline-forced > > (get-text-property (point) > > :org-clock-force-headline-inclusion)) > > (headline-included > > (or (null headline-filter) > > (save-excursion > > (save-match-data (funcall headline-filter)))))) > > (setq level (- (match-end 1) (match-beginning 1))) > > > > What do match-beginning/match-end return if headline-filter is nil? > > The save-match-data is not done, so we get the results of whatever > > random search was done last before this code executed. > > So I guess that despite my suspicions this code works (although I need to understand how). As for the failure, your example is of course highly unlikely in the above form[fn:1], but much more likely in the inline task case that bit you originally. But since expanding the vector to 100 elements or so fixes the problem and seems to be both cheap and expedient, I'd vote for that fix to go in and be done with it (perhaps with a footnote in the clock section of the manual to identify the limit). Nick Footnotes: [fn:1] I doubt anybody uses > 30-level deep trees, although I would not be surprised to hear otherwise :-)