From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/10866 Path: main.gmane.org!not-for-mail From: Hrvoje Niksic Newsgroups: gmane.emacs.gnus.general Subject: Re: timezone.el patterns in emacs 19.34 Date: 04 May 1997 02:41:41 +0200 Message-ID: References: <199705020844.EAA06520@kr-laptop.cygnus.com> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035150666 26891 80.91.224.250 (20 Oct 2002 21:51:06 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:51:06 +0000 (UTC) Return-Path: Original-Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.8.5/8.8.5) with SMTP id RAA15693 for ; Sat, 3 May 1997 17:52:04 -0700 Original-Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sun, 4 May 1997 02:41:49 +0200 Original-Received: (from hniksic@localhost) by jagor.srce.hr (8.8.5/8.8.4) id CAA15911; Sun, 4 May 1997 02:41:42 +0200 (MET DST) Original-To: ding@ifi.uio.no X-Save-Project-Gutenberg: X-Attribution: Hrv X-Face: Mie8:rOV<\c/~z{s.X4A{!?vY7{drJ([U]0O=W/xDi&N7XG KV^$k0m3Oe/)'e%3=$PCR&3ITUXH,cK>]bci&Ff%x_>1`T(+M2Gg/fgndU%k*ft [(7._6e0n-V%|%'[c|q:;}td$#INd+;?!-V=c8Pqf}3J In-Reply-To: Ken Raeburn's message of 03 May 1997 19:44:25 -0400 Original-Lines: 76 X-Mailer: Gnus v5.4.50/XEmacs 19.15 Xref: main.gmane.org gmane.emacs.gnus.general:10866 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:10866 Ken Raeburn writes: > Okay, so how would you get around the requirement of matching a > substring, without using regexps? Simply make as many routines as there are formats. For example, if the format is Wkd, blah blah then I search for week days, if I find them, look for `,', etc. It's tedious, but I can guarantee that it would be *much* faster than the current, Lisp code. > If you can do it, and get much better performance than we've got now > with the lisp code, great. But as I just indicated in other mail, > my trivial little patch already addresses the performance issue to > some degree. So you'll have to do even better. :-) I certainly won't do it before I get the exact numbers of how much time is spent in timezone.el, before and after your patch. It is too much work to speed up Summary buffer building by 5% or so. > And, by the way, if you do go ahead with this, I'd suggest returning > numbers instead of strings when practical. They can be turned into > strings easily enough in lisp, and the gnus-dd-mmm usage just converts > them back to numbers and discards the strings, which means more > needless garbage to collect. (Don't underestimate the cost of garbage > collection. I've managed to speed up some code by tweaking it to > allocate less short-term heap storage.) Yup. > > NO! I hate getdate.y. First, because of the `.y' thingie. :-) > > Aside from the substring issue, I think a parser would be well suited > to this task. I see two advantages to it: > * Tokenizes first, then looks for patterns in the tokens; this means > any backtracking doesn't have to re-process every character. > * Yacc sets up a FSM for matching multiple sequences in parallel (as > do the more sophisticated regexp matchers), so if a match is going > to be made, it'll be made in one pass; the hairy work is done at > build time. But it's huge, and we don't need all that cruft. In a C implementation of timezone.el, it would make little difference whether the parser is "intelligent" or not. > > Then, there are copyright problems with it. > > No, there aren't. Yes, there are. The public domain code is not to be introduced in important parts of Emacs, as it is compromisable. > > And, I'd like to have a fast routine that matches those 7 or so > > format strings. > > Yes, that's the problem I see with it -- it'll handle more than we > want. `getdate.y' would handle even more. > A date header saying "+23hours" is bogus, and should be treated > as such. Though if getdate.y matches more "real" date formats than > timezone-parse-date, I don't think it would be a bad idea to support > them as well, since this is timezone-parse-date we're talking about, > and not gnus-parse-conforming-date-header. If I ever rewrite `timezone-parse-date', it will recognize the dates it recognizes now. -- Hrvoje Niksic | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Good pings come in small packets.