Re: [O] Stack overflow in regexp matcher
On 2014-10-24 19:02, Charles Berry writes: > Alan Schmitt polytechnique.org> writes: > >> >> Hello, >> >> I've just got the following backtrace when opening an org >> file. Unfortunately I cannot reproduce it reliably, but I was wondering >> if others had seen something similar. >> > > I do. Try this. Start emacs 24.4.1. > > 1) Copy this line: > > CLOCK: [2013-07-22 Mon 12:29]--[2013-07-22 Mon 15:26] => 2:57 > > into a new *.org file. > > 2) Save and close the file and reopen. > > 3) If no such error, kill the text in the buffer, and yank it twice. > > 4) Repeat 2 and 3 till the message > >File mode specification error: (error "Stack overflow in regexp matcher") > > shows up. > > 5) prune lines from the file and try step 2 till the error disappears. > > > For me somewhere between 400 and 500 lines is the difference between opening > with no error message and opening with the message. Interesting. I don't use clocking, but the files in question use tags and logbooks. I can actually open the file when I try a second time, so to bisect this I would need to restart emacs each time. I'll try to see if I can get a reproduceable recipe on my side. Thanks, Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 signature.asc Description: PGP signature
[O] [ANN] Aggregate Table
Hi all I'm happy to announce the availability of the aggregation package. https://github.com/tbanel/orgaggregate Example: This is a source table: #+TBLNAME: source | Day | Quantity | |---+--| | Monday| 10 | | Monday|3 | | Tuesday | 52 | | Tuesday | 15 | | Tuesday | 18 | | Wednesday | 100 | | Wednesday | 23 | | Wednesday | 16 | This is an aggregated result computed by the package: #+BEGIN: aggregate :table source :cols "Day sum(Quantity)" | Day | sum(Quantity) | |---+---| | Monday|13 | | Tuesday |85 | | Wednesday | 139 | #+END: For those familiar with SQL, this is reminicent of the GROUP BY statement. For those familiar with the R statistics, this is reminicent of FACTORS. Features include: - Pure Emacs (no external dependency) - Wide variety of aggregation functions (sum, mean, max, count, median, etc.) - Calc underlying engine (the same used by Org spreadsheet) - Work in push or pull mode (pull mode uses so called dynamic blocks) - Any combination of key columns - and more To use it: - load in Emacs https://github.com/tbanel/orgaggregate/blob/master/org-aggregate.el This give access to the command: M-x org-insert-dblock:aggregate - look at the examples and documentation here: https://github.com/tbanel/orgaggregate - optionally load https://github.com/tbanel/orgaggregate/blob/master/org-insert-dblock.el This gives the following key-binding: C-c C-x i which insert any kind of dynamic blocks, including "aggregate" Feedback welcome. Have fun Thierry
Re: [O] [ANN] Aggregate Table
Thierry Banel writes: > Hi all > > I'm happy to announce the availability of the aggregation package. > https://github.com/tbanel/orgaggregate very interesting! thanks a lot! -- :: Igor Sosa Mayor :: joseleopoldo1...@gmail.com :: :: GnuPG: 0x1C1E2890 :: http://www.gnupg.org/ :: :: jabberid: rogorido ::::
Re: [O] Stack overflow in regexp matcher
On Fri, 24 Oct 2014, Gregor Zattler wrote:
Hi Charles, org-mode developers
* Charles Berry [24. Oct. 2014]:
I do. Try this. Start emacs 24.4.1.
1) Copy this line:
CLOCK: [2013-07-22 Mon 12:29]--[2013-07-22 Mon 15:26] => 2:57
into a new *.org file.
2) Save and close the file and reopen.
3) If no such error, kill the text in the buffer, and yank it twice.
4) Repeat 2 and 3 till the message
File mode specification error: (error "Stack overflow in regexp matcher")
shows up.
5) prune lines from the file and try step 2 till the error disappears.
For me somewhere between 400 and 500 lines is the difference between opening
with no error message and opening with the message.
Emacs 24.3.1 does not show this behavior - no error message.
I cannot reproduce this. I even tried with a file with 8264216
[rest deleted]
OK, thanks. It had to be something in my init.
I have (defun org-mode-reftex-setup () ... ) from
http://www.mfasold.net/blog/2009/02/using-emacs-org-mode-to-draft-papers/
in my init.
It turns out that
(re-search-forward "^[^%]*usepackage.*{biblatex}" nil t))
in reftex-using-biblatex-p is the culprit.
So, the ECM is to save a file like that decribed above without the *.org
extension.
Open it (in fundamental mode) and issue
M-: (re-search-forward "^[^%]*usepackage.*{biblatex}" nil t))
and get
eval: Stack overflow in regexp matcher
So, maybe this is not an org-mode issue. ??
HTH,
Chuck
Re: [O] Stack overflow in regexp matcher
On Sat, 25 Oct 2014, Charles C. Berry wrote:
On Fri, 24 Oct 2014, Gregor Zattler wrote:
Hi Charles, org-mode developers
* Charles Berry [24. Oct. 2014]:
I do. Try this. Start emacs 24.4.1.
1) Copy this line:
CLOCK: [2013-07-22 Mon 12:29]--[2013-07-22 Mon 15:26] => 2:57
into a new *.org file.
2) Save and close the file and reopen.
3) If no such error, kill the text in the buffer, and yank it twice.
4) Repeat 2 and 3 till the message
File mode specification error: (error "Stack overflow in regexp
matcher")
shows up.
5) prune lines from the file and try step 2 till the error disappears.
[snip]
It turns out that
(re-search-forward "^[^%]*usepackage.*{biblatex}" nil t))
in reftex-using-biblatex-p is the culprit.
So, the ECM is to save a file like that decribed above without the *.org
extension.
Open it (in fundamental mode) and issue
M-: (re-search-forward "^[^%]*usepackage.*{biblatex}" nil t))
and get
eval: Stack overflow in regexp matcher
So, maybe this is not an org-mode issue. ??
Further, changing that regexp to
"^[^%\n]*usepackage.*{biblatex}"
and byte-compiling reftex-parse.el.gz seems to make the problem go away.
This seems to be well-known problem:
http://www.emacswiki.org/emacs/MultilineRegexp
Still, I am not sure why this happens in 24.4.1 and not previously.
HTH,
Chuck
Re: [O] working with tables freezes emacs
Nicolas Goaziou writes: > Hello, > > Rasmus writes: > >> Xebar Saram writes: >> >>> i was wondering if anyone else have had these problems (using latest emacs >>> and org-mode from git): whenever i start working with tables and start >>> editing a cell emacs starts freezing, all emacscleint instances are frozen >>> and i have to kill emacs to get things back to work >>> >>> anyone else encountered this? is there a way i can try to debug this (im >>> not technically savvy at all) >> >> Yes, I experience it as well. I have not found a clear receipt to >> reproduce yet (in particular not in with emacs -q), though, but in my >> case key components are: emacsclient, tables and TAB to realign. > > Do you have any update on this? Do you still encounter the bug? It happened to me now when I was editing a table and clicked TAB. Debugger entered--beginning evaluation of function call form: * (byte-code "\301\302\303!\207" [quit-flag t eval (ignore nil)] 2) flyspell-post-command-hook() recursive-edit() debug(error (quit)) flyspell-post-command-hook This function is advised by :around advice: `ad-Advice-flyspell-post-command-hook' >From ac. I have not removed this since I don't use ac anymore. Maybe this will solve the issue. —Rasmus -- You people at the NSA are becoming my new best friends!
Re: [O] [PATH] Speedups to org-table-recalculate
Hi Michael
On Mon, Oct 20, 2014 at 12:41 PM, Michael Brand
wrote:
> Hi Nathaniel
>
> On Mon, Oct 20, 2014 at 3:56 AM, Nathaniel Flath
> wrote:
> > Thanks for the review! Updated patches attached. I believe I've fixed
> > everything you mentioned -
>
> Yes, thank you. I tried them out.
>
> > let me know if I missed something.
>
> > Subject: [PATCH 1/2] org-table.el: Add early return check to
> > org-table-recalculate
>
> > Subject: [PATCH 2/2] org-table.el: Print far fewer messages when
> recalculating
> > tables.
>
> http://orgmode.org/worg/org-contribute.html
> says: Line 2 is an empty line.
>
> I try to limit my commit subjects to 50 chars which is a rule for some
> projects and helpful for e. g. git log with certain options.
>
OK, will fix these in next set of pathces.
>
> > +(and all (org-table-execute-once-per-second
> > + log-last-time
> > + (message
> > + "Re-applying formulas to full table...(line %d)"
> > + (setq cnt (1+ cnt)
>
> Before trying out I have overseen it, setq does not increment on each
> line any more so it has to move before
> org-table-execute-once-per-second. Now probably better wrapped in a
> `when' instead of the original `and' with an added `progn'.
>
OK, good catch
>
> > +(org-table-execute-once-per-second
> > + log-first-time
> > + (message "Re-applying formulas...done" cnt))
>
> cnt is superfluous.
>
OK.
>
> Only during trying out I noticed: This message could still be kept as
> a feedback at least for single row updates, like e. g. Tab on a row
> with "#" in the first column, by changing log-first-time to (when all
> log-first-time).
>
> Or more conservative why not leave this message unconditional to avoid
> that any user could complain for any use case that all feedback
> messages disappeared like it would be the case for e. g. the typical
> "C-c C-c" on TBLFM? I think that would be a simple, safe compromise.
>
I'm fine with adding the (when all log-first-time). I don't want to leave
it
unconditional because as we discussed before, one message in my case
significantly slows down the table recalculation - and if there has
been no feedback then we are dealing with a small case where it could be
significant.
>
> Otherwise the right but not so simple thing to do would be to log this
> message for a simple "C-c C-c" on TBLFM and to not log it for only
> those cases that throw after other feedback messages like e. g.
> sometimes "C-u C-u C-c C-c" on TBLFM ("Table was already stable"), M-x
> org-table-iterate-buffer-tables and more. These repetition intensive
> use cases are the only ones that can profit noticeable from the
> conditional removal of this last message, aren't they?
>
I got tired of having to force tables to be reformated, so I advised
org-cycle to always recalculate a table, so I notice whenever I'm in a
table.
>
> Michael
>
