From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Wojciech Meyer Newsgroups: gmane.emacs.devel Subject: Re: Problems with xml-parse-string Date: Fri, 24 Sep 2010 18:34:05 +0100 Message-ID: References: <87zkvaiked.fsf@stupidchicken.com> <87vd5ymptn.fsf@stupidchicken.com> <87vd5x7ty2.fsf@stupidchicken.com> <87vd5wo48a.fsf@stupidchicken.com> <8739t03q2g.fsf@stupidchicken.com> <87k4mb2mfu.fsf@stupidchicken.com> <87pqw3nm4y.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: dough.gmane.org 1285349662 22651 80.91.229.12 (24 Sep 2010 17:34:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 24 Sep 2010 17:34:22 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 24 19:34:21 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OzCA8-000839-Lo for ged-emacs-devel@m.gmane.org; Fri, 24 Sep 2010 19:34:21 +0200 Original-Received: from localhost ([127.0.0.1]:41530 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OzCA7-0003Ah-Ua for ged-emacs-devel@m.gmane.org; Fri, 24 Sep 2010 13:34:19 -0400 Original-Received: from [140.186.70.92] (port=43751 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OzCA0-00039S-I4 for emacs-devel@gnu.org; Fri, 24 Sep 2010 13:34:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OzC9v-0002ia-Hc for emacs-devel@gnu.org; Fri, 24 Sep 2010 13:34:12 -0400 Original-Received: from mail-qy0-f169.google.com ([209.85.216.169]:55618) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OzC9v-0002iN-FW for emacs-devel@gnu.org; Fri, 24 Sep 2010 13:34:07 -0400 Original-Received: by qyk7 with SMTP id 7so1728543qyk.0 for ; Fri, 24 Sep 2010 10:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=spwPewuauZJGIlbWdYj8PJgqjCIw6wkYykCN1tb6PM8=; b=XKbUTqUuC2BJepfxahl/3ZJGUx6Ja/kig+TZAvR8qiCi3GhKMOAU6cqLhWCgDUZmFu dzCBZB0KziMVchWL0D6xbmgw5Og1Xr092GQfxcIAjkVAt8JIyhc0/xiX72xmQur8p3Wy 21D2Qf8lg+xXdp4mD0+3ZLa/VL8CA5fX6eIdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=BCPUNd21jadDJJRHKlkHtrpylbZVQ7EAtDayqRZpnNcphT3RcHVaxYfBXNcHw6+dQ1 uR+quWTblRBTNOVxL6ue9axUfAtpX2Gu20MuzG1XnILj/H3v/EJdVvUmubtvzu2UTtzn NR9YXAHd0j1oRGe14TR4xvhGv2bhD4bBXstpg= Original-Received: by 10.224.60.131 with SMTP id p3mr2640883qah.205.1285349645919; Fri, 24 Sep 2010 10:34:05 -0700 (PDT) Original-Received: by 10.229.31.139 with HTTP; Fri, 24 Sep 2010 10:34:05 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:130789 Archived-At: Sorry, I don't underdand your point at all. did you hear about abstract data structures? On 9/24/10, Lars Magne Ingebrigtsen wrote: > Chong Yidong writes: > >>> The main difference between sxml and xml.el output is that it has the >>> weird an unnecessary "@" node for the attributes and that it wastes a >>> cons in the attributes, isn't it? >> >> The xml.el output always has an alist for attributes after each tag; if >> there are no attributes, the element after the tag name is nil. In >> sxml, the `@' denotes an attribute list, which is omitted if no >> attributes exist. > > Yes. So it's yet another irregularity you have to check for. > > To take a concrete example: You want the src of the img node you have. > > xml.el: (cdr (assq 'img (cadr node))) > sxml.el: (if (and (consp (cadr node)) > (eq (caadr node) '@)) > (cadr (assq 'img node))) > > (And I'm not even sure that's correct. It's probably not. Which is my > point.) > > libxml: (cdr (assq :img (cdr node))) > > (The difference between libxml and xml.c for attributes is minuscule.) > >>> Other than that it has the same problem that xml.el has, in that text >>> nodes have to be special-cased, so you can't say assq or use simple >>> descent without testing. >> >> It is illogical to criticize sxml for wasting conses, while arguing for >> wrapping each text node in a cons. > > No, it is not. I'm sacrificing space for speed and regularity. sxml > wasting cons cells, and adding slowdowns at the same time. > >> Anyway, it is difficult to see how real the problem is without a >> concrete example. Could you provide one? I suspect that the real >> problem, if one exists, is Elisp's relatively weak support for list >> mapping and reduction; if that's the case, the correct solution is to >> pull in some of the relevant functions from the CL package. > > Here's a pretty piece of code, chosen at random: > > (defun nnrss-find-el (tag data &optional found-list) > "Find the all matching elements in the data. > Careful with this on large documents!" > (when (consp data) > (dolist (bit data) > (when (car-safe bit) > (when (equal tag (car bit)) > ;; Old xml.el may return a list of string. > (when (and (consp (caddr bit)) > (stringp (caaddr bit))) > (setcar (cddr bit) (caaddr bit))) > (setq found-list > (append found-list > (list bit)))) > (if (and (consp (car-safe (caddr bit))) > (not (stringp (caddr bit)))) > (setq found-list > (append found-list > (nnrss-find-el > tag (caddr bit)))) > (setq found-list > (append found-list > (nnrss-find-el > tag (cddr bit)))))))) > found-list) > > The horror! > > -- > (domestic pets only, the antidote for overdose, milk.) > larsi@gnus.org * Lars Magne Ingebrigtsen > > > -- Sent from my mobile device