From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/77771 Path: news.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.gnus.general Subject: Re: Debugger entered--Lisp error: (overflow-error "13419098521433281274") Date: Tue, 15 Mar 2011 17:50:04 +0100 Organization: Programmerer Ingebrigtsen Message-ID: References: <87lj0x4k59.fsf@fastmail.fm> <8739my3kmb.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1300210113 16488 80.91.229.12 (15 Mar 2011 17:28:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 15 Mar 2011 17:28:33 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M26093@lists.math.uh.edu Tue Mar 15 18:28:29 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PzY2n-0007Mt-3v for ding-account@gmane.org; Tue, 15 Mar 2011 18:28:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1PzY2m-0006ZV-2q; Tue, 15 Mar 2011 12:28:28 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PzY2k-0006ZC-6j for ding@lists.math.uh.edu; Tue, 15 Mar 2011 12:28:26 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PzY2f-0008J0-Q2 for ding@lists.math.uh.edu; Tue, 15 Mar 2011 12:28:26 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1PzY2f-0003OS-2o for ding@gnus.org; Tue, 15 Mar 2011 18:28:21 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PzY2f-0007Ir-1p for ding@gnus.org; Tue, 15 Mar 2011 18:28:21 +0100 Original-Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Mar 2011 18:28:21 +0100 Original-Received: from larsi by cm-84.215.51.58.getinternet.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Mar 2011 18:28:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-Lines: 26 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cm-84.215.51.58.getinternet.no Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEX09PbNzdOdnaM7Oj9h YGYKCQ10dHr////+//4JekSdAAACS0lEQVQ4jXXUwW6jMBAAUJOuthxjQ1GO2ElRjivG5l5woz2X OOdiqL+g2uRIpZXCZ++EAKFVdy5R/DL2MJ5Ajtc4dfPABXI8UiaoxxtlAMDSPno4USEozcEYZUo3 gyMmUNqYa1QcvyxHYBV9HuBwg5PgrAYzRn47Q9Dotm72c6D1DUpcF0O5lF4zynGvCZjCWpU5PF+B TfDW/x5U/5FSwa/g0Q1c1ne6B85GIF7iLlAlhTFSVdiIAUihLpAnTpW8toJPUPfQuF2RiXUuxpYQ sqnXCLVwOq93mDBB0NxhzwthneNWTE1syUKHeBelzJkV0Ry8onq8HJN7Fmult61+FumjyhRUnkjE 7T464jH5YPYNVESI2UW1hJAIy+KQE/YVSGQyW0v+KYP0URzSxuWC8+UXqPcya3aWs60328rjJCqN 1NLFtGtnGSGnkTEg8clX586bgGm9YbWpdO64f+4+3AghFOnSkwzAveLktnKAyOwfMiacFdL9bru2 0wPg8DjQWjtb6C3CuRkAb/RFFCCx67BqO3I/AEUoqztQmXPaRxgzRHgZmneFc9LYjrR+N0DygfD0 Q0MiNtZHOA7QUBxCuQghF4lbLbHeEWwNUobr/slj7nfjGQ1WqvI7/AMmWDH3T/czKLK/2CunnVve d5/hjzEZ7mW9p3a+VZG+G/laS8cjiP0BHMomDUwaB6Xka8j8zZSRq+zNHOJASWwNPIXDA2ptVfpo XuIAZIMjCUMGS3QFvwKzj4MM+hjuo8WxYNuF4KsFpfNXxvfxX/gHmq5GDzc4H0wAAAAASUVORK5C YII= Mail-Copies-To: never X-Now-Playing: Don Cherry's _Blue Lake_: "Dollar and Okay's Tune" User-Agent: Gnus/5.110014 (No Gnus v0.14) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:3IJeiia7Of/0y0ZuZxDBRPlMn+A= X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:77771 Archived-At: Ted Zlatanov writes: > LMI> I think the best way to handle this is to make the MODSEQ into a string > LMI> if it's more than mumble number of characters long. > > ...so basically replace (\d+) with "\1" if that's bigger than MAXINT? I've now had a peek at the code, and we basically don't use MODSEQ from FETCH at all. We use HIGHESTMODSEQ from SELECT, though, which has the same problems. So this is what I think should be done: 1) The parser should just remove "\\bMODSEQ ([0-9])" totally before parsing FETCH 2) HIGHESTMODSEQ should be read as a string 3) The thing that compares old to new HIGHESTMODSEQ should take both numbers and strings, but compare things as strings I'll make those changes now. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen