Re: historical question
Rudolf Schlatte writes: > cage writes: > >> Hi! >> >> Some person (including me) was wondering when the ASDF project >> started; on the fediverse someone guessed that the 25th anniversary >> could be near. Is that true? > > If you need a definitive answer, you could ask Dan Barlow, he's on the > fediverse at @d...@brvt.telent.net ... he isn't on that address, but in my defense it was rewritten by gmane. Try @ dan @ brvt dot telent dot net
Re: historical question
cage writes: > Hi! > > Some person (including me) was wondering when the ASDF project > started; on the fediverse someone guessed that the 25th anniversary > could be near. Is that true? If you need a definitive answer, you could ask Dan Barlow, he's on the fediverse at @d...@brvt.telent.net
Re: Rejiggering the branches
"Robert Goldman" writes: > If stable seems bad, is there another name we could use to avoid renaming? > Like maint for "maintenance"? > > I don't love maint, because it's too close to main, and it seems like main > has an edge in familiarity if not in meaningfulness. > > legacy? > > Unless we can come up with something better than stable, it seems like the > least-worst alternative. But there's all week to come up with something > better! > In the first email you said that the purpose of that branch was to permit continuation of the 3.3 release series, so maybe call the branch "v3.3"? That way, there can be multiple such branches without resorting to "stable", "oldstable" etc. names. Rudi
Re: [asdf-devel] [armedbear-devel] Upgrade issues
On Jan 21, 2013, at 20:08, Faré fah...@gmail.com wrote: ABCL is one of the three implementations, together with CLISP and CMUCL, where I ultimately punted on ASDF hot-upgrade, by just trying to rename away the ASDF package if it's too old. I don't know if you're interested in making the kind of package surgery I was indulging in work, but it involves rehoming symbols from ASDF to subpackages such as ASDF/COMPONENT, including for class slot names. Hi Fare, I appreciate your work on asdf, and bug reports are always good. If you can describe your problems as a sequence of forms that we can type in to observe breakage, things shouldn't be too hard to fix. It would be cool to have an abcl that can support all of asdf. Rudi ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] suggestion for aserve.asd
On Dec 20, 2012, at 03:21, Robert Goldman rpgold...@sift.info wrote: On 12/19/12 Dec 19 -8:04 PM, Faré wrote: On Wed, Dec 19, 2012 at 4:57 PM, Robert Goldman rpgold...@sift.info wrote: You don't need acl-file any more. You can now use cl-source-file.cl, which is exported from ASDF. You can make legacy-acl-source-file inherit from cl-source-file.cl and cut the ACL-FILE class entirely. That will take care of using the .cl extension instead of .lisp. Actually, an acl-file is still required, because there's a method on perform. On the other hand, that method needs to be changed to play well with asdf-output-translations, and could simply be an :around method to (handler-bind (((or style-warning warning) #'muffle-warning)) (call-next-method)) or something (untested). Actually, portable aserve has two layers. It has an acl-file, and it has legacy-acl-source-file. I believe that the former is unnecessary, but the warning muffler on legacy-acl-source-file is still needed. On general principles, I don't like the idea that there are warnings that need muffling: I think any mature system should build without warnings. If you muffle some warnings that need muffling, sooner or later you always end up muffling a NEW warning that you wish you hadn't muffled Agreed on both counts, but I prefer minimally invasive surgery, especially in an old and creaky system like paserve. Anyway, the suggested changes are committed now, which will hopefully make Fare's job a bit easier. Rudi ___ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
