From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Hackney Newsgroups: gmane.emacs.devel Subject: plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!) Date: Tue, 4 Jun 2013 18:44:09 -0400 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1370385884 31644 80.91.229.3 (4 Jun 2013 22:44:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Jun 2013 22:44:44 +0000 (UTC) Cc: Stefan Monnier , Emacs development discussions To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 05 00:44:46 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ujzy2-0000wo-Sr for ged-emacs-devel@m.gmane.org; Wed, 05 Jun 2013 00:44:39 +0200 Original-Received: from localhost ([::1]:53570 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ujzy2-0005KY-Fh for ged-emacs-devel@m.gmane.org; Tue, 04 Jun 2013 18:44:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53686) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ujzxx-0005J5-Qt for emacs-devel@gnu.org; Tue, 04 Jun 2013 18:44:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ujzxw-0008Qd-HJ for emacs-devel@gnu.org; Tue, 04 Jun 2013 18:44:33 -0400 Original-Received: from mail-ie0-x230.google.com ([2607:f8b0:4001:c03::230]:64138) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ujzxw-0008QS-7H for emacs-devel@gnu.org; Tue, 04 Jun 2013 18:44:32 -0400 Original-Received: by mail-ie0-f176.google.com with SMTP id at20so1839676iec.21 for ; Tue, 04 Jun 2013 15:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=haxney.org; s=google; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=StHgqnEBEVR/UpU4XYtfxUteBGgaSSjNHLn95lZwmWQ=; b=gfWGOMoRsRfd9hJOcExRakvuO6S+TqfxvsL/ECF192Wllb9R4k3sToXKDBCCD1Fpa4 LuCVXEgSvNXMgKUa5D4tJ2ieTWZmRZH9DtwE4GyUxV5VSNbIJ4kBwJ0fiZA3WSCzNJ+5 X7Or1uBXu18J8Fk8cOkClUpVaugpirz/j2sn8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-gm-message-state; bh=StHgqnEBEVR/UpU4XYtfxUteBGgaSSjNHLn95lZwmWQ=; b=R/RaFK//Se9dMl0Xl9IBHy686ERoLlz3S9T1uvYF1R8sCwgmuYt94Wez89wk2qK44r pJ41YAd1JrT1AR3vz0yEzLXrwj6TLc4ccumUMEjBuIOp58+Sh5RQiSYny3bW1Mz0rPAC fqcgt+e4LGYk/+7bTfQelti9jpqd7KVDk9dPIjmIq8QzqKCvz5klMW+pvOKfMQfYKSBX NELLYBJHSijkXsJMLzmOMpsW0+vu7KPwNhxDPE4sN0zBsoflyy7JsGCyXkGwF+EbkxzK K3jtjVKWgOSl42fT79WTiMDHA+qQpGDKTxNcSGRIrbOMbUb2oduj5hd9AW6sR7vkg3Ub KzBQ== X-Received: by 10.50.115.67 with SMTP id jm3mr1955184igb.65.1370385869127; Tue, 04 Jun 2013 15:44:29 -0700 (PDT) Original-Received: by 10.64.246.194 with HTTP; Tue, 4 Jun 2013 15:44:09 -0700 (PDT) X-Gm-Message-State: ALoCoQmH6XcUd4dmCu9BKGRIzRSVAqugBbrvzW6m7fC7/4FNzLWdtFRza5xD4v9J+1EUIoue4yim X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::230 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:160087 Archived-At: Looking at Bug#13291 ("The package description buffer needs an URL button"), I'm having a crisis of confidence in my plan to use `cl-defstruct' to represent `package-desc' structures. The big problem with `cl-defstruct' in this case is its lack of extensibility. We are going to want to add additional slots to `package-desc' structures over time, but doing so would require redefining `package-desc' each time. `cl-defstruct' requires that structures be of the exact length given in the definition of the structure; if, for example, `package-desc-name' gets a vector with an unexpected length, it will signal an error: (error "package-desc-name accessing a non-package-desc") This is desirable for structures which don't change, but we are going to want all sorts of extra slots in `package-desc' structures. As a result, I'm going to refactor my refactor: I'll make `package-desc' structures into plists, so that future additions don't break existing code. I don't think this should be that invasive; all accesses to `package-desc' structures occur through `package-desc-*' functions anyway, so not much will change from my current iteration. What a time to change my mind; I had just finished all of the coding changes. Daniel Hackney wrote: > Dmitry Gutov wrote: >> Any news on this? > > I was finishing up on exams, so this had to be put on hold. I'm > starting up on it again. I think it's close to a mergable state, so > I'll finish up the NEWS entry and submit the patch for merging. > >> I've been holding off on Bug#13291 both because it would complicate >> the rebase of this changeset, and also because I'd like to use the >> test harness you have here. > > Sounds good. I'll try to get things on my end totally finished so > development can resume on the new version. > >> Daniel Hackney writes: >>> I'll do a better job of explaining the whole patch. Should I include >>> that in some sort of file in the repo or just on the mailing list? >>> Would a detailed-ish explanation of the changes and rationale be >>> appropriate for the ChangeLog or NEWS files? >> >> You can start with ChangeLog files. When writing a changelog entry, >> one usually briefly describes and sometimes justifies the mechanical >> transformations being performed on the code, and it helps other people >> understand the changes. > > Since it is a complete refactoring, what should I say? Should I include > a line for each new or changed function, or simply refer people to the > NEWS file? > >> I see you've also already started on NEWS entries. > > How does it look so far? Any suggestions on how to improve it? > >>> About package-x.el, is the HTML and RSS updating functionality actually >>> used? Currently, the only way to access the functionality is calling >>> `package-maint-add-news-item' or the non-interactive >>> `package-upload-buffer-internal' directly. GNU ELPA clearly doesn't use >>> the version in package-x.el, as the HTML generated is not what >>> package-x produces. >> >> Probably not. Melpa and Elpakit don't seem to be using it either. >> >>> Can I consider it unused and delete it? If not, I'll refactor it with >>> the rest of the code. >> >> Personally, I'd delete them, but that's not my call. Maybe decorate them >> with FIXMEs, leave them unfixed and see if anyone complains up until the >> pretest? > > I did some porting and they should continue to work, although they don't > do much of anything useful, just like before. > > One other change I made, which probably deserves some discussion, is > that I created a folder "test/automated/data" which is intended to hold > test-related data. I created a subfolder "package" (so it is > "test/automated/data/package") which contains a test "archive-contents" > file, as well as test elisp files. My hope is that such a directory > could be useful for other tests which need example data. > > I also added a rule in the "Makefile.in" to skip byte-compilation of the > files in "data". > > -- > Daniel Hackney -- Daniel Hackney