Re: [asdf-devel] component-property
02.02.2013, 05:29, Faré fah...@gmail.com: On Fri, Feb 1, 2013 at 8:19 PM, Anton Vodonosov avodono...@yandex.ru wrote: 01.02.2013, 23:23, Faré fah...@gmail.com: After discussion with people on #lisp and via private chat, I decided to use a shorter name. Here is what was released in 2.27: :long-name Another System Definition Facility :homepage http://common-lisp.net/projects/asdf/; :bug-tracker https://launchpad.net/asdf/; :mailto asdf-devel@common-lisp.net :source-control (:git git://common-lisp.net/projects/asdf/asdf.git) Another useful slot would be :purpose, it could specify what the library is: web server, db client, image processing library, data-structures library, etc. The values in this slots are tags from some specified taxonomy. To avoid creating the taxonomy from scratch we could start for example with the tag tree from cl-user.net. In in the future we could want to improve the taxonomy. If the new improved taxonomy is incompatible with the old one, we can then introduce new slot, :purpose2, specifying that it can hold values from new taxonomy. I think this is an idea for future, it's probably too big to be in the scope of ASDF3 s Why not. And if some people end up actually using component-property for such useful purpose, or otherwise make successful use of it, I am willing to reconsider the deprecation of component-property, and/or my successor will. Maybe it's clear already, but I am not arguing for/against component-property. Just share this idea because it is now being discussed what metadata attributes are useful. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
After discussion with people on #lisp and via private chat, I decided to use a shorter name. Here is what was released in 2.27: :long-name Another System Definition Facility :homepage http://common-lisp.net/projects/asdf/; :bug-tracker https://launchpad.net/asdf/; :mailto asdf-devel@common-lisp.net :source-control (:git git://common-lisp.net/projects/asdf/asdf.git) —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Hopefully, they ban not just gay marriage, but straight marriage too, and at last we have separation of state and marriage. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
Fare == Far Far writes: Fare After discussion with people on #lisp and via private chat, I decided Fare to use a shorter name. Here is what was released in 2.27: Fare :long-name Another System Definition Facility Fare :homepage http://common-lisp.net/projects/asdf/; Fare :bug-tracker https://launchpad.net/asdf/; Fare :mailto asdf-devel@common-lisp.net Fare :source-control (:git git://common-lisp.net/projects/asdf/asdf.git) Are the valid key values for :source-control specified? I guess they're all pretty obvious like :git, :cvs, :darcs, etc. But mercurial is a bit odd. Is it :mercurial or :hg? Or maybe it doesn't really matter? Ray ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
Raymond Toy toy.raym...@gmail.com
writes:
Fare == Far Far writes:
Fare After discussion with people on #lisp and via private chat, I
decided
Fare to use a shorter name. Here is what was released in 2.27:
Fare :long-name Another System Definition Facility
Fare :homepage http://common-lisp.net/projects/asdf/;
Fare :bug-tracker https://launchpad.net/asdf/;
Fare :mailto asdf-devel@common-lisp.net
Fare :source-control (:git
git://common-lisp.net/projects/asdf/asdf.git)
Are the valid key values for :source-control specified? I guess
they're all pretty obvious like :git, :cvs, :darcs, etc. But
mercurial is a bit odd. Is it :mercurial or :hg?
:svn or :subversion ?
Are :sccs and :rcs supported?
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
01.02.2013, 23:23, Faré fah...@gmail.com: After discussion with people on #lisp and via private chat, I decided to use a shorter name. Here is what was released in 2.27: :long-name Another System Definition Facility :homepage http://common-lisp.net/projects/asdf/; :bug-tracker https://launchpad.net/asdf/; :mailto asdf-devel@common-lisp.net :source-control (:git git://common-lisp.net/projects/asdf/asdf.git) Another useful slot would be :purpose, it could specify what the library is: web server, db client, image processing library, data-structures library, etc. The values in this slots are tags from some specified taxonomy. To avoid creating the taxonomy from scratch we could start for example with the tag tree from cl-user.net. In in the future we could want to improve the taxonomy. If the new improved taxonomy is incompatible with the old one, we can then introduce new slot, :purpose2, specifying that it can hold values from new taxonomy. I think this is an idea for future, it's probably too big to be in the scope of ASDF3 ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
On Fri, Feb 1, 2013 at 8:19 PM, Anton Vodonosov avodono...@yandex.ru wrote: 01.02.2013, 23:23, Faré fah...@gmail.com: After discussion with people on #lisp and via private chat, I decided to use a shorter name. Here is what was released in 2.27: :long-name Another System Definition Facility :homepage http://common-lisp.net/projects/asdf/; :bug-tracker https://launchpad.net/asdf/; :mailto asdf-devel@common-lisp.net :source-control (:git git://common-lisp.net/projects/asdf/asdf.git) Another useful slot would be :purpose, it could specify what the library is: web server, db client, image processing library, data-structures library, etc. The values in this slots are tags from some specified taxonomy. To avoid creating the taxonomy from scratch we could start for example with the tag tree from cl-user.net. In in the future we could want to improve the taxonomy. If the new improved taxonomy is incompatible with the old one, we can then introduce new slot, :purpose2, specifying that it can hold values from new taxonomy. I think this is an idea for future, it's probably too big to be in the scope of ASDF3 s Why not. And if some people end up actually using component-property for such useful purpose, or otherwise make successful use of it, I am willing to reconsider the deprecation of component-property, and/or my successor will. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org No matter what language you use, a Sufficiently Smart Compiler(TM) will be able to find an efficient implementation for whatever apparently difficult problem you specify. However, a Sufficiently Smart Compiler(TM) for arbitrary problems is itself an AI-complete problem. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
FWIW, here's the list of properties in LibCL before it died. An incomplete readme is attached. A few fields were specific to LIBCL (most belong in ASDF properties); I was bootstrapping this on the side out of necessity. Hasn't a similar effort been started in Quicklisp? (:name :website ;:license :bsl :short-desc :maintainer () :docpath :tags () :todo nil :provides () :load-unless nil :version :date :source ()) Here's an example of what I wrote for Hunchentoot. (:name Hunchentoot :website http://weitz.de/hunchentoot/; :license :bsd :short-desc web server :maintainer (http://common-lisp.net/mailman/listinfo/tbnl-devel; http://weitz.de/patches.html;) :docpath :tags (:web) :todo nil :provides () :load-unless nil :version :date 2010-08-29 :source (:svn svn://bknr.net/svn/trunk/thirdparty/hunchentoot 4603)) - Daniel*** :maintainer (...) A list of name place (where place is an email or irc or forum url or whatever) Contact info for maintenance issues. *** :docpath relative-path *** :tags (...) Each package may also be marked by a list of tag keywords. Users can specify these when selecting what to install. Here are the initial tags. :core - a core LibCL package :doc - a documentation tool :graphics - image loading, saving, and manipulation :util - simple utility functions (i.e. general-purpose tools) :ffi - this package relies on ffi (non-lisp) bindings :reader - tools for modifying the lisp reader :test - testing frameworks ... *** :todo notes Things that should probably happen before the release. *** :version version Indicate the version number if this was a tagged release. Sometimes a simple bugfix appears after a tagged release. Need a suffix to mark when these minor changes are being used. *** :date YYY-MM-DD Indicate the date of the release or snapshot. *** :source (...) The darcs hash may rely on darcs2. It can be obtained by a variant of the following incantation. # darcs changes --last 1 --xml-output | grep hash= | sed -e s/.*hash='\(.*\)'.*/\1/ Many of Edi's libraries can be found by running # svn propget -R svn:externals svn://bknr.net/svn/ediware Known source types (:cvs url module revision-specifier) ; cvs revs are often specified as -D 2010-12-34 to get all the commits on 2010-12-33... (:darcs url hash) (:git url sha1-hash) (:svn url revision) (:wget url filename) ; so #mv filename $canonicalname # or need more? ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
Faré fah...@gmail.com writes: On the one hand, I am deprecating component-property in ASDF3, Why? What will be the new mechanism for what component-property provides? Zach ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
Faré fah...@gmail.com writes: On the one hand, I am deprecating component-property in ASDF3, Why? What will be the new mechanism for what component-property provides? I propose that any data that component-property is actually used for should be in appropriate slots of the system. This will introduce a new round of synchronization headaches whenever a new slot is added. The existing mechanism is forward and backward compatible indefinitely. Zach ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
I'm still curious as to _why_ component property is going away, not (just) how you think folks should work around its absence. thanks, Cyrus On Jan 31, 2013, at 9:10 AM, Faré fah...@gmail.com wrote: On the one hand, I am deprecating component-property in ASDF3, Why? What will be the new mechanism for what component-property provides? I propose that any data that component-property is actually used for should be in appropriate slots of the system. I will gather a list from things in quicklisp. As for extensibility, there is already defclass for that. Or comments, when the meta-data isn't for machine consumption. This will not happen for ASDF 2.27, but hopefully for 3.0. Even after it happens, a compatibility layer will be provided for old code; but its use for new code will be strongly discouraged, e.g. by droppng the data that doesn't fit the backward-compatibility schema, and/or issuing an error if the system is not whitelisted. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Economics is not about goods and services; it is about human choice and action. — Ludwig von Mises ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
On the one hand, I am deprecating component-property in ASDF3, Why? What will be the new mechanism for what component-property provides? I propose that any data that component-property is actually used for should be in appropriate slots of the system. This will introduce a new round of synchronization headaches whenever a new slot is added. The existing mechanism is forward and backward compatible indefinitely. Synchronization is NOT necessary to add new slots. If you want a new slot, just create a new class with that slot, and use both :defsystem-depends-on and :class in your defsystem form. This usage pattern wouldn't work on ASDF 1 or early ASDF 2, but it works quite well since ASDF 2.016 from June 2011 and later. Then, a year after your slot gets merged into asdf:system, you can stop using your defsystem-depends-on. The properties mechanism is already totally and irremediably useless. Automation across systems is impossible unless everyone agrees on a schema, or you somehow merge the zillions of possible ad-hoc schemas; but properties actually make synchronization *harder* than lack thereof, by making it cheaper to diverge and more expensive to converge. Properties without a synchronized schema are useless within a single system, where it is easier, safer and more powerful to just directly store data in a Lisp variable rather than in the properties. In other words, properties not only do not serve the purpose they look like they are addressing, but cannot possibly serve any purpose. They are a lure and a waste of everyone's time — an attractive nuisance. I propose they be replaced by the real thing, i.e. agreeing on a schema. Before we do, we would be well inspired to look at similar metadata schemas from Debian, RPM, Hackage, PLaneT, etc. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Failure is the opportunity to begin again, more intelligently. — Henry Ford, who had two flops before founding Ford Motor Co. ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
Faré fah...@gmail.com writes: On the one hand, I am deprecating component-property in ASDF3, Why? What will be the new mechanism for what component-property provides? I propose that any data that component-property is actually used for should be in appropriate slots of the system. This will introduce a new round of synchronization headaches whenever a new slot is added. The existing mechanism is forward and backward compatible indefinitely. Synchronization is NOT necessary to add new slots. If you want a new slot, just create a new class with that slot, and use both :defsystem-depends-on and :class in your defsystem form. This usage pattern wouldn't work on ASDF 1 or early ASDF 2, but it works quite well since ASDF 2.016 from June 2011 and later. Then, a year after your slot gets merged into asdf:system, you can stop using your defsystem-depends-on. Feel free to adopt this technique for your proposed website slot, so it does not cause compatibility problems. Please do not remove other techniques. The properties mechanism is already totally and irremediably useless. Automation across systems is impossible unless everyone agrees on a schema, or you somehow merge the zillions of possible ad-hoc schemas; but properties actually make synchronization *harder* than lack thereof, by making it cheaper to diverge and more expensive to converge. Properties without a synchronized schema are useless within a single system, where it is easier, safer and more powerful to just directly store data in a Lisp variable rather than in the properties. In other words, properties not only do not serve the purpose they look like they are addressing, but cannot possibly serve any purpose. They are a lure and a waste of everyone's time — an attractive nuisance. I think it would be pretty easy to get everyone to agree on a schema for properties, and it would be useful to do so. Zach ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
Synchronization is NOT necessary to add new slots. If you want a new slot, just create a new class with that slot, and use both :defsystem-depends-on and :class in your defsystem form. This usage pattern wouldn't work on ASDF 1 or early ASDF 2, but it works quite well since ASDF 2.016 from June 2011 and later. Then, a year after your slot gets merged into asdf:system, you can stop using your defsystem-depends-on. Feel free to adopt this technique for your proposed website slot, so it does not cause compatibility problems. Please do not remove other techniques. There is no compatibility problem whatsoever with adding optional slots. And I *will* severely cripple the properties slot, then remove it eventually, but not until after everyone has moved away from it for a year or two. The properties mechanism is already totally and irremediably useless. Automation across systems is impossible unless everyone agrees on a schema, or you somehow merge the zillions of possible ad-hoc schemas; but properties actually make synchronization *harder* than lack thereof, by making it cheaper to diverge and more expensive to converge. Properties without a synchronized schema are useless within a single system, where it is easier, safer and more powerful to just directly store data in a Lisp variable rather than in the properties. In other words, properties not only do not serve the purpose they look like they are addressing, but cannot possibly serve any purpose. They are a lure and a waste of everyone's time — an attractive nuisance. I think it would be pretty easy to get everyone to agree on a schema for properties, and it would be useful to do so. For the same price, we can agree on a schema, add it to defclass system, and get rid of the attractive nuisance that is component-properties. Silently incompatible is not the same as compatible. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org War does not determine who is right — only who is left. — Bertrand Russell ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
Faré fah...@gmail.com writes: Feel free to adopt this technique for your proposed website slot, so it does not cause compatibility problems. Please do not remove other techniques. There is no compatibility problem whatsoever with adding optional slots. I just tried, and got this: Error while trying to load definition for system wwwoops from pathname /home/xach/src/lisp/wwwoops/wwwoops.asd: Invalid initialization argument: :WEBSITE in call for class #STANDARD-CLASS ASDF:SYSTEM. [Condition of type ASDF:LOAD-SYSTEM-DEFINITION-ERROR] There *is* a compatibility problem. Zach ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
Feel free to adopt this technique for your proposed website slot, so it does not cause compatibility problems. Please do not remove other techniques. There is no compatibility problem whatsoever with adding optional slots. I just tried, and got this: Error while trying to load definition for system wwwoops from pathname /home/xach/src/lisp/wwwoops/wwwoops.asd: Invalid initialization argument: :WEBSITE in call for class #STANDARD-CLASS ASDF:SYSTEM. [Condition of type ASDF:LOAD-SYSTEM-DEFINITION-ERROR] There *is* a compatibility problem. I haven't added the slots yet, so of course it won't work. As for disabling properties on old versions of ASDF that don't actually support them, that's what #+asdf3 is for, just like #+asdf2 before it. Hopefully, two years from now we can assume everyone has moved from ASDF2 to ASDF3, just like today we can safely assume no one uses ASDF1 anymore. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Oignez villain, il vous poindra ; poignez villain, il vous oindra. — Rabelais ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
Faré fah...@gmail.com writes: I haven't added the slots yet, so of course it won't work. As for disabling properties on old versions of ASDF that don't actually support them, that's what #+asdf3 is for, just like #+asdf2 before it. When it is time to add support for a bug-tracker-url slot, will there be a feature for that? Or will that be done via subclassing? Now is a good time to request such features, before ASDF 3 is actually released. After it is released, and until another major release follows, subclassing will be the recommended way. I request a slot called properties that can hold arbitrary key/value data. Zach ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
I did an analysis of how system properties are used in Quicklisp systems, and this suggests that the following initargs be added: :website-url === widely requested. the URL suffix makes it less ambiguous. :bug-tracker-url === Zach's request that makes a *whole* lot of sense :development-email === More actionable name than :author-email. Or maybe just use mailto: URL in bug-tracker-url? :long-name === we have :long-description already, so why not? I believe some kind of :source-control slot might be useful, though between SVN, GIT, Mercurial, etc., there is no common URL pattern, so we'd have to specify some structure. Either a list of `(,vcs-keyword ,@url+options) or a command to checkout / clone the repository to be parsed, or something. Here are the uses of component properties in Quicklisp systems: asd's that directly use asdf:component-property: *** yaclml = :features === property for version comparison. See arnesi below. *** amazon-ecs = :website === Yes, need to be added to ASDF 3. *** hemlock.asd = :last-loaded-as-source === bad implementation of latin1 encodings with lifted from ASDF 1's bad implementation of load-source-op. Let's just use asdf-encodings for that, and/or use UTF-8, furgossake. asd's that use :properties in defsystem: *** arnesi, arnesi+ = :features === misguided property used for version comparison and pseudo #+features version comparison should use :version. The pseudo-features should probably be replaced by either having separate systems or actual features, depending on their use pattern. If actually useful, create a subclass with a :component-features initarg. *** lkcas, thopter = :long-name === used by the Makefile through component-property. I could add that to defclass system, or he could use a subclass. *** cl-irc cliki-bot rss cl-syslog com.informatimago.clext com.informatimago.clisp com.informatimago.clmisc com.informatimago.common-lisp.arithmetic om.informatimago.common-lisp.bank com.informatimago.common-lisp.cesarum com.informatimago.common-lisp com.informatimago.common-lisp.csv com.informatimago.common-lisp.cxx com.informatimago.common-lisp.data-encoding com.informatimago.common-lisp.diagram com.informatimago.common-lisp.ed com.informatimago.common-lisp.graphviz com.informatimago.common-lisp.heap com.informatimago.common-lisp.html-base com.informatimago.common-lisp.html-generator com.informatimago.common-lisp.html-parser com.informatimago.common-lisp.http com.informatimago.common-lisp.interactive com.informatimago.common-lisp.invoice com.informatimago.common-lisp.lisp com.informatimago.common-lisp.lisp.ibcl com.informatimago.common-lisp.lisp.stepper com.informatimago.common-lisp.lisp-reader com.informatimago.common-lisp.lisp-sexp com.informatimago.common-lisp.lisp-text com.informatimago.common-lisp.parser com.informatimago.common-lisp.picture com.informatimago.common-lisp.regexp com.informatimago.common-lisp.rfc2822 com.informatimago.common-lisp.rfc3548 com.informatimago.common-lisp.telnet com.informatimago.common-lisp.unix linc com.informatimago.lispdoc com.informatimago.lua com.informatimago.cocoa-playground com.informatimago.objcl com.informatimago.rdp com.informatimago.rdp.basic com.informatimago.rdp.basic.example com.informatimago.rdp.example com.informatimago.susv3 com.informatimago.common-lisp.tools.make-depends com.informatimago.xcode spartns xlunit = (WTF uninterned symbols, really?) #:author-email === somewhat useful piece of data #:date === You're never going to get anything but stale information here. (#:albert #:output-dirs) === An absolute pathname in a .asd? Braindamage! (#:albert #:formats) === should be moved to some albert-system class slots (#:albert #:docbook #:template) (#:albert #:docbook #:bgcolor) (#:albert #:docbook #:textcolor) (#:albert #:docbook #:dtd) *** portableaserve = (WTF The same albert thing, just incompatibly?) (system author email) (albert presentation output-dir) (albert presentation formats) (albert docbook dtd) (albert docbook template) !! Albert should probably use its own subclass to put its information *** com.clearly-useful.generic-collection-interface = :com.clearly-useful === whatever you're doing, use a subclass. *** metatilities = :ait-timeout :system-applicable-p === same comment *** ucw ucw-core = it.bese.ucw.system::version === WTF? use :version instead. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org On two occasions I have been asked [by members of Parliament!], `Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. — Charles Babbage ___ asdf-devel
Re: [asdf-devel] component-property
In 2.26.174, I added the following initargs to system with system-FOO accessors. I also added an :initform nil to all those optional metadata slots and previous ones. :long-name Another System Definition Facility :website-url http://common-lisp.net/projects/asdf/; :bug-tracker-url https://launchpad.net/asdf/; :developers-email asdf-devel@common-lisp.net :source-control (:git git://common-lisp.net/projects/asdf/asdf.git) If there is more automatically-processable metadata for which you'd like a defined slot in ASDF3, now is the time to speak. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org What a lot of trouble to prove in political economy that two and two make four; and if you succeed in doing so, people cry, 'It is so clear that it is boring.' Then they vote as if you had never proved anything at all. — Frederic Bastiat, What Is Seen and What is Not Seen, 1850 ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
[asdf-devel] component-property
Dear Red, as a follow up to my previous email, I eventually added in 2.26.174 the following initargs to defclass system, with system-FOO accessors. :long-name Another System Definition Facility :website-url http://common-lisp.net/projects/asdf/; :bug-tracker-url https://launchpad.net/asdf/; :developers-email asdf-devel@common-lisp.net :source-control (:git git://common-lisp.net/projects/asdf/asdf.git) The down side is that until ASDF2 is end-of-lifed, you'll have to #+asdf3 all these things either individually or together via e.g. (eval `(defsystem ... #+asdf3 ,@'(...) ...), (defsystem ... . #.(or #+asdf3 '(...)) or some other such ugliness. The upside is that with this standardization, odds are higher that this metadata can be used to automate processing of some sort across systems. If there are more slots that you need, now is a good time to suggest them. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org What a lot of trouble to prove in political economy that two and two make four; and if you succeed in doing so, people cry, 'It is so clear that it is boring.' Then they vote as if you had never proved anything at all. — Frederic Bastiat, What Is Seen and What is Not Seen, 1850 ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
(Replying in public to this private email; I hope this is not a faux-pas.) On Thu, Jan 31, 2013 at 11:23 PM, Daniel Herring dherr...@tentpost.com wrote: :long-name Another System Definition Facility :website-url http://common-lisp.net/projects/asdf/; :bug-tracker-url https://launchpad.net/asdf/; :developers-email asdf-devel@common-lisp.net :source-control (:git git://common-lisp.net/projects/asdf/asdf.git) Slight ribbing: (:git ...) has the same problem as the original properties mechanism; it won't catch errors such as (:get ...) Indeed. An external tool with a documented specification is required here. But at least there's a clear intent and the beginning of an actual convention, and it all makes sense. You might have left the properties as-is and just added warnings when an unknown property name was used. Possibly. It's still time to have parse-component-form call a better validation function that does such checks, and otherwise have some allow-other-keys mechanism. See also https://bugs.launchpad.net/asdf/+bug/1007335 Meh. A good project for ASDF4, if anyone is foolish enough to undertake it. Actually bug https://bugs.launchpad.net/asdf/+bug/953489 reminds me that one could use #-asdf3 :allow-other-keys #-asdf3 t to say yeah, there are optional slots here that aren't defined before asdf3. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org No one has the right to a position; everyone has the right to positions being well filled. — Ernest Renan ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] component-property
Fare On the other hand, now is a good time for me to add new slots to system objects. Fare I will add a website slot in 2.26.171, though you'll have to Fare #+asdf3 :website #+asdf3 http://xxx; for now. Does :website do anything other than record that info? If not, then why not use :url? I actually pushed 2.26.171 without adding any such slot yet. I'm open to debate on naming things. And I reinstantiated the previous properties interface for backward compatibility, until everyone adopts the new solution (which may take years). —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org The main difference between a computer salesman and a used car salesman is that the used car salesman can probably drive and knows when he's lying. - Peter da Silva ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
